The ARB extension is a superset of the older SGIX extension. Any
hardware that can support the SGIX version can also support the ARB
version. In Mesa, any driver that supports one also supports the
other. This unification just simplifies some bits of code.
- Use a lookup table for log2.
- Compute (float) (1 << ipart) by tweaking with the exponent directly to
avoid integer overflow and float conversion.
- Also table negative exponents to avoid float division and branching.
- Implement util_fast_exp as function of util_fast_exp2.
- Sort extensions by ARB, then EXT, then vendor by name
- Remove redundant (only one of GL_{ARB,EXT,NV}_texture_rectangle) or
duplicate extension strings
The GL_OBJECT_TYPE_ARB query is handled directly in
_mesa_GetObjectParamterivARB because it is only supported in the
extension version of the shanding language API. glGetProgramiv and
glGetShaderiv should not accept this enum.
The GL_ARB_shader_objects spec says that glAttachShaderARB is supposed
to return GL_INVALID_OPERATION if a shader is attached to a program
where it is already attached. _mesa_attach_shader perviously returned
without error in this case.
Special care must be taken when calling compiler generated SSE2 functions
from the runtime generated SSE2: saving the xmm registers, and notify gcc
the stack is not 16byte aligned.
It would be more efficient to keep the stack pointer 16byte aligned, but
too hairy, and not consistent in all x86 architectures.
This has been tested in linux x86 and windows x86 userspace. Not tested on
x86-64 because it is broken for other reasons (even without this change).
Added an x86-64 CPUID function and use it to detect 3Dnow! If 3Dnow!
is available, use _mesa_3dnow_transform_points4_3d_no_rot,
_mesa_3dnow_transform_points4_perspective,
_mesa_3dnow_transform_points4_2d_no_rot, and _mesa_3dnow_transform_points4_2d.
This fixes long standing bug #8724.
The i965 driver previously had it's own set of code to convert
fixed-function TNL state to a vertex program. Core Mesa has code to
do this, so there is no reason to duplicate that effort in the driver.
In fact, this duplication leads to bugs when other aspects of the Mesa
infrastructure change.
