Age | Commit message (Collapse) | Author |
|
st_program.h
Remove p_shader_tokens.h
Include st_context.h for st_context symbol.
Include p_state.h for PIPE_MAX_SHADER_INPUTS symbol.
Remove unnecessary forward declarations.
st_cb_bitmap.c
st_cb_clear.c
Include p_shader_tokens.h now that st_program.h doesn't include it.
|
|
laying down the foundation for everything and implementing most of the
stuff.
linking, gl_VerticesIn and multidimensional inputs are left.
|
|
|
|
|
|
|
|
This was being calculated the same way in two different places.
Now just do it in st_translate_fragment_program().
|
|
Was being calculated and not used. Also was probably incorrect...
|
|
use correct number of vertex inputs
fix not running pipeline in case of edgeflags
changes to mesa to tgsi translation still very broken
|
|
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).
|
|
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.
|
|
|
|
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 _mesa_reference_vert/fragprog() wherever we assign program pointers.
Fixes a memory corruption bug found with glean/api2 test.
Another memory bug involving shaders yet to be fixed...
Picked from gallium-0.1
|
|
|
|
If texturing happens to be enabled when glBitmap() is called, need to be
careful about choosing a sampler unit, etc.
|
|
The return value was never used.
|
|
|
|
|
|
Brian's patch to clean up the shader interfaces.
|
|
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...
|
|
|
|
|
|
|
|
The CSO returned by pipe->create_vs_state() can't be passed to the
private draw module. That was causing glRasterPos to blow up.
Add a 'draw_shader' field to st_vertex_program for use with the private
draw module.
Change st_context->state.vs type from cso_vertex_shader to st_vertex_program.
|
|
|
|
This fixes an out of bounds array write that was causing the glsl/bump demo to render incorrectly.
|
|
Unfortunately, the generated fragment shader code is effectively unusable until
it handles quad->mask.
|
|
for each fragment program.
|
|
|
|
This reverts commit 6dcfddb8e2ec2bfb6187b912807fa65f28da2c5e.
|
|
|
|
|
|
proper linking.
Previously, programs were translated independently during validation.
The problem is the translation to TGSI format, which packs shader
input/outputs into continuous slots, depends on which vertex program is
being paired with which fragment shader. Now, we look at the outputs
of the vertex program in conjunction with the inputs of the fragment shader
to be sure the attributes match up correctly.
The new 'linked_program_pair' class keeps track of the associations
between vertex and fragment shaders. It's also the place where the TGSI
tokens are kept since they're no longer per-program state but per-linkage.
Still a few loose ends, like implementing some kind of hash/lookup table
for linked_program_pairs.
|
|
|
|
Remove/disable the attrib/slot mapping arrays in a few places.
Work in progress...
|
|
Allow driver custom allocation within cached objects. The shaders
are currently twiced (by cso layer and by the program itself).
|
|
TGSI_ATTRIB_x tokens still present and used in a few places.
Expanded set of TGSI_SEMANTIC_x tokens for describing the meaning
of inputs/outputs. These tokens are in a crude state ATM.
Lots of #if 0 / disabled code to be removed yet, etc...
Softpipe and i915 drivers should be in working condition but not heavily tested.
|
|
This is a step toward removing TGSI_ATTRIB_ tokens.
Basically, when translating Mesa programs to TGSI programs, pass in input and
output register re-maps, plus interpolation info.
There's some known breakage (cubemap.c) so more to be done...
|
|
|
|
|
|
|
|
|
|
They're now totally independent of the actual shaders.
Also, implemented in terms of pipe_buffer_handles/objects.
|
|
Renamed pipe_fs_state to pipe_shader_state since it can be used for both
vertex and fragment shader info.
|
|
We need to do these initializations before initializing the Mesa context
because context init involves creating texture/program/etc objects.
|
|
Handling of constants might change. For now, the st_fragment_program struct
contains a pipe_constant_buffer (not a pointer).
|
|
Not sure the generated program looks correct though...
|
|
softpipe/state_tracker --> state_tracker/
softpipe/ --> pipe/
softpipe/generic --> pipe/softpipe/
I don't think pipe is a great name, but I disliked all the others too.
Luckily it's fairly easy to rename with git, so this can be revisited
later.
|