> commit 5126683e3b971ccfb51e50e560750ce44e86bae8
> Author: Luca Barbieri <l...@luca-barbieri.com>
> Date: Fri Apr 2 05:23:32 2010 +0200
>
> gallium/util: add util_format_is_supported to check for pack/unpack
>
> This improves the code by making it more readable, and removes
> special knowledge of S3TC and other formats from softpipe.
> @@ -92,7 +92,7 @@ def write_format_table(formats):
> u_format_pack.generate(formats)
>
> for format in formats:
> - print 'const struct util_format_description'
> + print 'struct util_format_description'
> print 'util_format_%s_description = {' % (format.short_name(),)
> print " %s," % (format.name,)
> print " \"%s\"," % (format.name,)
I don't agree with this. Making the format description table mutable when the
only formats that are potentially unsupported due to patent issues are s3tc
variants makes no sense. S3TC formats *are* special. There is nothing to
generalize here.
> commit 52e9b990a192a9329006d5f7dd2ac222effea5a5
> Author: Luca Barbieri <l...@luca-barbieri.com>
> Date: Fri Apr 2 04:48:42 2010 +0200
>
> gallium/util: load s3tc on demand
>
> This changes the S3TC function pointers to be initialized to stubs
> that load the S3TC library and then delegate to the real functions.
>
> If the S3TC library fails to load, the function pointers are replaced
> with a "nop" function.
> The code is also changed to attempt to load the library only one time.c
>
> Note that unlike checking for a flag, this method has no performance
> cost at all.
>
> The use of the "nop" functions also allows to avoid most checks, that
> are only preserved when the function does non-trivial work.
Replacing the conditionals with a no-op stubs is a good optimization.
But attempting to load s3tc shared library from the stubs is unnecessary. Stubs
should have an assert(0) -- it is an error to attempt any S3TC (de)compression
when there's no support for it.
Jose
------------------------------------------------------------------------------
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
