When generating a fragment program from fixed function, checking
texUnit->_ReallyEnabled is not sufficient, need texUnit->Enabled too
since the former also represents texture enables from an active vertex
shader.
The 965 path wasn't setting pClipRects for batch submission since it didn't
want kernel cliprect handling before. The 915 path also grew the INTEL_NO_HW=1
option for testing just driver overhead.
It's not worth the extra effort to avoid a free/malloc, and we'd rather
auto-size the reloc data buffer at some point so we don't need to have
max_relocs.
As-is, if the texture was too large for the target, an assertion would fail.
Now check proxy texture first and if it works, then test non-proxy target.
The indirect_dispatch.h and indirect_table.c source files use
gl_and_glX_API.xml in their generation rather than glX_API.xml, but it
wasn't listed in their prerequisites. In turn, gl_and_glX_API.xml uses
glX_API.xml, but this is already listed in $(COMMON_GLX).
Make use of the make automatic variables $@ (the target) and $< (first
prerequisite) to clean up the commands for the glapi generation. This
improves readability and guards against typos since words are repeated
less frequently.
Put the path to indent and the flags to call it with in configs/default
rather than in the Makefile. This makes it easier to change the values
globally.
The Taylor series notably fails at producing sin(pi) == 0, which leads to
discontinuity every 2*pi. The quadratic gets us sin(pi) == 0 behavior, at the
expense of going from 2.4% THD with working Taylor series to 3.8% THD (easily
seen on comparative graphs of the two). However, our previous implementation
was producing sin(pi) < -1 and worse, so any reasonable approximation is an
improvement. This also fixes the repeating behavior, where the previous
implementation would repeat sin(x) for x>pi as sin(x % pi) and the opposite
for x < -pi.
The failure mode that was a available was:
reloc 1 -> target_buf
exec: PRESUMED_OFFSET wrong, buffer migrates, r1 entry updated.
reloc 2 -> target_buf
exec: suppose buffer migrates again. PRESUMED_OFFSET wrong. r2 entry updated.
reloc 1 -> target_buf
exec: suppose buffer doesn't migrate. PRESUMED_OFFSET right. no relocations
performed. r1 has stale pointer at original location.
Failures were reported with OGLconform's VBO test and SPECviewperf90, though
I haven't confirmed that this fixes it.
In addition to potentially binding when it was about to be mapped anyway,
failure to use CACHED_MAPPED means eating a full wbinvd on validate. Thanks to
airlied for catching this.
