| Age | Commit message (Collapse) | Author |
|---|
|
There's really no need for two negation fields. This came from the
GL_NV_fragment_program extension. The new, unified Negate bitfield applies
after the absolute value step.
|
|
|
|
|
|
|
|
due to the two read ports limit into temp memory may need the MAD_2 instruction
for the second instruction of the decomposed XPD.
While here, also try to avoid MAD_2 for MAD if all 3 inputs are temps but the
temps aren't actually distinct.
|
|
|
|
eg: #include "shader/program.h" and remove -I$(TOP)/src/mesa/program
|
|
Mostly:
- update #includes
- update STATE_* token code
|
|
Use the same input map handling for fftnl and vertex programs. It doesn't
enable any new functionality (should make it easy to support per-vertex
materials though), but the code is much cleaner.
|
|
|
|
submit the vertex weights to hw, which will enable broken vertex programs
errorneously using them to work. Note however that this will only work
if glWeight is used, there is no code in mesa at all to deal with weight
vertex array (glWeightPointerARB).
|
|
order leading to very bogus rendering (for instance WoW intro screen mentioned in #8250).
|
|
the change in the r200 driver accordingly.
|
|
inputs.
|
|
and texture inputs to them. Not widely tested yet. This should eliminate all fallbacks due to vertex programs, except writes to back facing colors, or when exceeding a hw limit (12 temps, 12 attribs etc.).
|
|
and instead use _mesa_insert_mvp_code().
|
|
for fog in vertex programs.
|
|
computation into the vertex program (not yet fixed for swtnl). Simplify (and correct) the VTX_TCL_OUTPUT_VTXFMT handling when using vertex programs, turns out it's solely driven by the needs of the past-vertex stage of the pipeline, this should fix lockups with ill-specified applications using vertex programs (for instance applications enabling fog but not writing to fog coord output will now get (conformant) undefined results instead of lockups).
|
|
defined to some default value by the spec (fogcoord yzw, normal w, secondary color w), by replacing those components with zero/one respectively using swizzling.
|
|
|
|
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).
|
|
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.
|
|
instead
|
|
vertex program code. Fix authors. Correct slightly wrong check to determine if ran out of temps. Simplify check to determine if ran out of max instructions. Correctly report used native temps. Always kick off program translation when ProgramStringNotify is called (otherwise the reported native resources used queried might be wrong).
|
|
|
|
determine if we actually have a program. See "[r300] TCL fallback with Quake3".
|
|
Fixes bug reported by Chris Rankin.
Added some new comments.
|
|
from Chris Rankin).
Also, fix some bad casts.
|
|
"gl_" to match other structs.
|
|
used swizzle and writemask flags are identical to the bits used on the hardware, use a macro to error out if these assumptions are no longer true.
|
|
only tested on r300.
|
|
when it's a nv_vp as there could be issues.
|
|
Clean up the r200 vertex program code a bit.
|
|
generic attribs cause a fallback, but otherwise it seems to work quite well. Passes all glean vertProg1 tests with the exception of the degnerated LIT case (which is a hw limitation), as well as runs the r200 render path of doom3/quake4 (1.1 patch needed for quake4). The code is heavily borrowed from the r300 driver as vertex programs encoding is almost identical. arb_vertex_program is not yet announced by default and still needs to be enabled via driconf.
|
