The idea here is to eliminate the set_edgeflags() call in pipe_context
by treating edgeflags as a regular vertex element.
Edgeflags provoke special treatment in hardware, which means we need to
label them in some way, in this case we'll be passing them through the
vertex shader and labelling the vertex shader output with a new TGSI
semantic (TGSI_SEMANTIC_EDGEFLAG).
Add a GLbitfield64 type and several macros to operate on 64-bit
fields. The OutputsWritten field of gl_program is changed to use that
type. This results in a fair amount of fallout in drivers that use
programs.
No changes are strictly necessary at this point as all bits used are
below the 32-bit boundary. Fairly soon several bits will be added for
clip distances written by a vertex shader. This will cause several
bits used for varyings to be pushed above the 32-bit boundary. This
will affect any drivers that support GLSL.
At this point, only the i965 driver has been modified to support this
eventuality.
I did this as a "squash" merge. There were several places through the
outputswritten64 branch where things were broken. I foresee this
causing difficulties later for bisecting. The history is still
available in the branch.
Conflicts:
src/mesa/drivers/dri/i965/brw_wm.h
Translate vertex shaders independently of fragment shaders.
Previously tried to make fragment shader semantic indexes always start
at zero and exclude holes. This was unnecessary but meant that vertex
shader translation had to be adjusted to take this into account.
Now use a fixed scheme for labelling special FS input semantics
(color, etc), and another fixed scheme for the generics.
With this, vertex shaders can be translated independently of the bound
fragment shader, assuming mesa has done its own job and ensured that
the vertex shader provides at least the inputs the fragment shader is
looking for. The state-tracker didn't attempt to do anything about
this previously, so it shouldn't be needed now.
Should be easier to read and work with than the older ways of emitting
TGSI tokens.
Also, emit simpler TGSI than previously:
- translate away source and dest extended modifiers
- translate away the SWZ opcode
Previously, the FOGC attribute contained the fragment fog coord, front/back-
face flag and the gl_PointCoord.xy values. Now each of those things are
separate fragment program attributes. This simplifies quite a few things in
Mesa and gallium.
Need to test i965 driver and fix up point coord handling in the gallium/draw
module...
mesa allocates both frontface and pointcoord registers within the fog
coordinate register, by using swizzling. to make it cleaner and easier
for drivers we want each of them in its own register. so when doing
compilation from the mesa IR to tgsi allocate new registers for both
and add new semantics to the respective declarations.
It's legal for ARB_vertex_program programs to not write to result.position.
The results are undefined in that case. This assertion was causing us to
abort/exit though.
The recent increase ST_MAX_SHADER_TOKENS to 8K causes stack overflows on
windows.
Failure to allocate is not being propagated to the caller. This is not
a regression since the previous _mesa_malloc result wasn't being
checked as well. Unfortunately it is not easy to fix, as the callers of
these functions do not have failure propagation mechanism either, and
so on. So leaving a just fixme note for now.
s/FRAG_RESULT_DEPR/FRAG_RESULT_DEPTH/
s/FRAG_RESULT_COLR/FRAG_RESULT/COLOR/
Remove FRAG_RESULT_COLH (NV half-precision) output since we never used it.
Next, we might merge the COLOR and DATA outputs (COLOR0, COLOR1, etc).
In some cases, the vertex program output's semantic info didn't match up
with the fragment program's input semantic info. This info is now explicitly
passed into the st_translate_fragment_program() function.
Use the code in cso_context.c rather than st_cache.c.
Basically, binding of state objects now goes through the CSO module.
But Vertex/fragment shaders go through pipe->bind_fs/vs_state() since they're
not cached by the CSO module at this time.
Also, update softpipe driver to handle NULL state objects in various places.
This happens during context destruction. May need to update other drivers...
Update the Makefiles and includes for the new paths.
Note that there hasn't been no separation of the Makefiles yet, and make is
jumping all over the place. That will be taken care shortly. But for now, make
should work. It was tested with linux and linux-dri. Linux-cell and linux-llvm
might require some minor tweaks.
