Age | Commit message (Collapse) | Author |
|
|
|
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.
|