| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
We weren't rendering correctly if the first thing drawn was a point (PRIM_MODE_POINT=0).
|
|
|
|
|
|
Unfortunately, the generated fragment shader code is effectively unusable until
it handles quad->mask.
|
|
location.
|
|
the clipping code.
(really done by Keith)
|
|
|
|
This, plus expanding all instructions ahead of time, seems to have improved
the performance of program execution by 8x or so.
|
|
|
|
|
|
This reverts commit 6dcfddb8e2ec2bfb6187b912807fa65f28da2c5e.
|
|
This reverts commit 57b5d3605745c96ddc2b6de7d50c93db65ba1257.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
Build a buffer of contigous vertices and indices at the backend of our
software transformation/clipping path. This will become the mechanism
for emitting buffers of vertices to rasterization hardware.
This is similar to but not the same as the post-transform vertex cache.
In particular, these vertices are subject to clipping, culling, poly offset,
etc. The vertices emitted will all be used by hardware.
TODOs include the actual transformation to hardware vertex formats, moving
this out of softpipe to somewhere more useful and allowing >1 primitive to
share the generated VB.
|
|
|
|
|
|
Still need to produce decl instructions for vertex shaders...
|
|
|
|
|
|
|
|
Remove/disable the attrib/slot mapping arrays in a few places.
Work in progress...
|
|
|
|
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...
|
|
|
|
state
|
|
|
|
This will be used for:
GL_NV_transform_feedback, or similar GL3 functionality
glRasterPos
GL selection/feedback modes
|
|
This will be used for:
GL_NV_transform_feedback, or GL3 equivalent.
RasterPos
GL select/feedback modes
|
|
|
|
|
|
A few functions which were basically duplicated between softpipe and the
i915 driver are now re-used:
draw_emit_vertex_attr()
draw_compute_vertex_size()
|
|
Added a new draw_set_twoside_attributes() function for specifying which
vertex attributes are to be copied/replaced when a polygon is back-facing.
|
|
|
|
to cpy.
One less dependency on the TGSI_ATTRIB_x flags.
This requires setting the vertex_info->interp_mode[] values in the i915 driver and passing them to draw_set_vertex_attributes().
|
|
In emit_poly() we need to compute header.edgeflags from the vertex
edge flags. Also need to set header.det so later stages can determine
front/back orientation.
|
|
The code is all in place, but mostly disabled for now:
In t_vp_build.c, write the VERT_RESULT_PSIZE register
In sp_state_derived.c, need to emit vertex point size if drawing points.
In setup_point() use the point size from the vertex.
|
|
|
|
|
|
The bits for the N user-defined planes are now set in the vertex_header->clipmask.
See some detailed comments about this in the clip_line() function.
CLIP_USER_BIT no longer exists.
|
