remove code to deal with non-normalized texture coordinates for tex rect targets (swtcl tex coord translation stage, tcl tex matrix adaption) and use the chip's native handling of such coords instead (!!!). Seems noone noticed those bits in the se_coord_fmt reg, even though it works fairly similar to r200 (except it's set per-unit and always active, so only enable it for texture rectangles).
Redefine the BYTE_TO_FLOAT() and SHORT_TO_FLOAT() macros to avoid problems
converting 0 to exactly 0.0
This goes against the OpenGL spec (see table 2.6) but solves problems
when doing byte -> float -> ubyte conversion for particular texture formats.
Basic facility for playing back captured aubfiles. Requires a small
hack to the drm to disable command verification on the cmd_buffer
ioctl. Doesn't exactly replay as commands are normally delivered as
batchbuffers but are captured and replayed as commands on the ring.
cause a vtxfmt fallback directly when hitting NewList for radeon and r200 drivers, otherwise we'll mix up tcl and vtxfmt path for some reason. This fixes a warzone2100 asssertion failure.
Cope with memory pool fragmentation by allowing a second attempt at
rendering operations to take place after evicting all resident
buffers.
Cope better with memory allocation failures throughout the driver and
improve tracking of failures.
make really sure R200_VAP_PROG_VTX_SHADER_ENABLE is never set when we're already in a tcl fallback, otherwise the chip will instantly lock up when vertex progs are enabled the next time not in a tcl fallback (fixes for instance guaranteed lockup running any program which uses vertex progs with tcl_mode=0 and then later with tcl_mode=1).
only allow VERT_ATTRIB_MAX instead of _TNL_ATTRIB_MAX for inputs of vertex programs (fixes a segfault since the result of the shift is undefined otherwise, and it may happen that _TNL_ATTRIB_POINTSIZE will be tried to read, unlike all other attribs this however may be unitialized (might be a bug in itself)).
make sure vertex programs are only enabled on the hw when they are really enabled, not just when a program enables vertex progs (could still be not enabled due to some error). Otherwise the hw potentially would try to execute a not valid (not set up at all) vertex program, likely leading to lockups. Hopefully fixes #8060.
There were two sets of bugs in the vertex program (ARB and NV)
protocol. First, several of the ARB functions were missing the
'doubles_in_order="true"' annotation. Second, after the ARB decided
that glVertexAttrib*ARB functions must not alias fixed-function state
for GLSL, Nvidia re-assigned GLX protocol opcodes for
glVertexAttrib*NV (circa Septeber 2004). For some reason gl_API.xml
was never updated to reflect this, and the updated version of the
GL_NV_vertex_program spec never made into the registry.