This is cleaner than the if statements in the code. Also np2 textures
should in theory support linear filtering, but fglrx doesn't seem to
like it. This needs further investigation. So far we've never used
linear filtering on np2 textures, so there should not be a
regression. Furthermore I think shader support is more important than
filtering, since NP2 textures are mostly used for 1:1 copying to the
screen.
ATI cards prior to the radeon HD series did not have unconditional non
power of two support. So far we've used texture_rectangle for that, or
created a bigger power of two texture with padding. This had the
disadvantage that we had to correct the coordinates, which causes
extreme problems with shaders(doesn't work, pretty much).
Both the MacOS and the fglrx driver have support for
GL_ARB_texture_non_power_of_two, and run it on the hardware as long as
we stay within the texture_rectangle limitations. This allows us to
have conditional non power of two textures with normalized
coordinates. This patch adds an internal extension, and the code
creates a regular GL_TEXTURE_2D texture with NP2 size, but refuses
mipmapping, filtering and texture_rectangle incompatible
operations. This makes np2 textures work with shaders on fglrx and
macos.
The opengl extension mentioned in that code was never finished, and as
far as I know there is no way to make use of tangent data in the d3d
fixed function pipeline as well.
Note that GL_ATI_envmap_bumpmap is not the same as
GL_ATI_fragment_shader. envmap_bumpmap is used together with the
regular opengl ffp pipeline and is not used (other than for
pixelformats) if GL_ATI_fragment_shader is used.
This patch adds a new field to the state templates. If this extension
field is != 0, then the line is only applied to the final state table
if the extension is supported. Once a line is applied to the final
table, all further templates for this state from the same pipeline
part are ignored. This allows removing some extension checks from the
state handlers, which cleans them up and saves a few CPU cycles when
applying the states.
This patch enables texture filtering for textures using the A4R4G4B4
format, I can see no reason why it shouldn't be filtered (especially
considering X4R4G4B4 has it).
This creates an nvts version of this function, and removes the nvts
code from the original one. The nvts version is used by the nvts
pipeline implementation, the original one by the nvrc-only, atifs and
ffp one.
As long as we have the shader constants in misc, it is best to keep
all the code that affects shader constants, like bumpenvmat setting,
in there as well.
This code creates the structures and the pipeline selection, as well
as the caps filling. It does not yet move the actual code around,
since this will be a bigger task.
When a sampler is changed and unconditional NP2 textures are not
supported, the texture matrix may need adjustment. The sampler state
function checks for that, and calls the texture transform setting
function in that case. However, samplers are a misc state, and the
texture transform flags a vertex state. Thus split up the code and
move the matrix changes to the vertex side.
Since atifs is only doing the fragment pipeline replacement right now
there is no need for the shader backend structure any longer. The ffp
private data is stored in new fragment pipeline private data(which
could potentially be set to equal the shader private data if needed).
It isn't related to the shader backend any longer. The nvts_enable in
the ffp code isn't quite right as well, it should be moved away once
there is a dedicated nvts fragment pipeline replacement
Destroying the stateblock potentially references the shader backend.
If the stateblock has active shaders when it is released, the shader's
destructor will tell the shader backend to destroy the corresponding
resources. This was exposed by my patch that moved the glsl program
lookup table into the backend's private data.
Calling shader_select() from inside depth_blt() isn't necessarily
safe. shader_select() assumes CompileShader() has been called for the
current shaders, but that depends on STATE_VSHADER / STATE_PIXELSHADER
being applied. That isn't always true when depth_blt() gets called,
with the result that sometimes GLSL programs could be created with no
shader objects attached.
Stefan Dösinger