commit 4f106f44a32eaddb6cf3fea6ba5ee9787bff609a
Author: Brian Paul <brianp@vmware.com>
Date: Mon Dec 13 14:06:08 2010 -0700
st/mesa: reorganize vertex program translation code
Now it looks like the fragment and geometry program code.
Also remove the serial number fields from programs. It was used to
determine when new translations were needed. Now the variant key is
used for that. And the st_program_string_notify() callback removes all
variants when the program's code is changed.
commit e12d6791c5e4bff60bb2e6c04414b1b4d1325f3e
Author: Brian Paul <brianp@vmware.com>
Date: Mon Dec 13 13:38:12 2010 -0700
st/mesa: implement geometry shader varients
Only needed in order to support per-context gallium shaders.
commit c5751c673644808ab069259a852f24c4c0e92b9d
Author: Brian Paul <brianp@vmware.com>
Date: Sun Dec 12 15:28:57 2010 -0700
st/mesa: restore glDraw/CopyPixels using new fragment program variants
Clean up the logic for fragment programs for glDraw/CopyPixels. We now
generate fragment program variants for glDraw/CopyPixels as needed which
do texture sampling, pixel scale/bias, pixelmap lookups, etc.
commit 7b0bb99bab6547f503a0176b5c0aef1482b02c97
Author: Brian Paul <brianp@vmware.com>
Date: Fri Dec 10 17:03:23 2010 -0700
st/mesa: checkpoint: implement fragment program variants
The fragment programs variants are per-context, as the vertex programs.
NOTE: glDrawPixels is totally broken at this point.
commit 2cc926183f957f8abac18d71276dd5bbd1f27be2
Author: Brian Paul <brianp@vmware.com>
Date: Fri Dec 10 14:59:32 2010 -0700
st/mesa: make vertex shader variants per-context
Gallium shaders are per-context but OpenGL shaders aren't. So we need
to make a different variant for each context.
During context tear-down we need to walk over all shaders/programs and
free all variants for the context being destroyed.
This fixes endless vertex shader recompilations in find_translated_vp
if the shader contains an edge flag output.
NOTE: This is a candidate for the 7.9 branch.
Signed-off-by Brian Paul <brianp@vmware.com>
Fixes this GCC warning.
state_tracker/st_program.c: In function 'st_print_shaders':
state_tracker/st_program.c:735: warning: 'sh' may be used uninitialized in this function
If the pipe driver has shader stencil export we can accelerate DrawPixels
using it. It tries to pick an S8 texture and works its way to X24S8 and S8X24
if that isn't supported.
Implement the pipe_rasterizer_state::sprite_coord_enable field
in the draw module (and softpipe) according to what's specified
in the documentation.
The draw module can now add any number of extra vertex attributes
to a post-transformed vertex and generate texcoords for those
attributes per sprite_coord_enable. Auto-generated texcoords
for sprites only worked for one texcoord unit before.
The frag shader gl_PointCoord input is now implemented like any
other generic/texcoord attribute.
The draw module now needs to be informed about fragment shaders
since we need to look at the fragment shader's inputs to know
which ones need auto-generated texcoords.
Only softpipe has been updated so far.
This removes references to symbols in draw module for OpenGL ES build.
As OpenGL ES does not support feedback/selection mode, draw module is
used in pathes that will never be reached. However, if the symbols are
referenced, it will bloat the final shared libraries unnecessarily.
This is serious when LLVM is enabled.
This fixes the progs/glsl/pointcoord.c demo. But this isn't a proper fix.
We really need a TGSI_SEMANTIC_POINT_COORD label so that the draw module
can determine which fragment input / vertex output slot needs to be set
up with the point coordinate info. We've been using generic slot 0 so far.
This would also require telling the draw module about fragment shaders
(something it doesn't have at this time).
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).
It is possible to have a 1-instruction vertex shader before expanding
pos_invarient. Not sure what this assert achieved, but at least move
it where it is correct.
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.
