Mesa has a bug that causes a crash due to a NULL pointer dereference
with the R200 driver when making a context current that has
GL_FRAGMENT_SHADER_ATI enabled. This patch works around this bug by
making sure that GL_FRAGMENT_SHADER_ATI is disabled before deactivating
a context, and reactivates it afterwards. The context manager keeps
GL_ATI_FRAGMENT_SHADER generally enabled, except if the context is in 2D
blit mode.
For each pixel format we store a flag in the table whether it supports
post pixelshader blending. Before applying blending or during a
context switch we verify that blending is turned off for the
format. In case of R32F this gave a 5-6x performance boost (without
filtering and software conversion).
This adds code for handling fixed function fragment processing with the
GL_ATI_fragment_shader extension. This is a sort-of programmable
interface for fragment processing at the level of shader model 1.4 in
d3d. This code is of use on r200, r250 and r280 cards(radeon 8500 to
9200) which do not support GL_ARB_fragment_program, but support pixel
shader 1.4 on Windows. This code is somewhat a counterpart to the
existing fragment processing code using GL_NV_register_combiners and
GL_NV_texture_shader.
Since the shader backend implementations might track opengl resources in
their private data inform them about reset calls. For example, the atifs
backend keeps track of the replacement shaders, which are lost during an
opengl context recreation.
The whole control structures in directx.c get terribly confusing with
the various codepaths for texturing and different shader
implementations. It is also hard to reflect the shader model
decisions this way too. This patch moves the shader specific parts of
the caps code into the shader backend where we can set our caps
dependent of the shader model decisions and without complex caps flag
checks.
Generating the shader ID and parts of the shader prolog and epilog was
done by the common vertexshader.c / pixelshader.c, which is ugly.
This patch doesn't get rid of all the uglyness, somewhen we'll still
have to sort out the relationship of [arb|glsl]_generate_shader and
[arb|glsl]_generate_declarations.
Stefan Dösinger