| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Spotted by Brian Paul.
|
|
Spotted by Jakob Bornecrantz.
|
|
|
|
|
|
|
|
The linux-debug target builds...
|
|
Use front/back instead of cw/ccw throughout.
Also, use offset_point/line/fill instead of offset_cw/ccw.
Brings gallium representation of this state into line with its main
user, and also what turns out to be the most common hardware
representation.
This fixes a long-standing bias in the interface towards the
architecture of the software rasterizer.
|
|
When points or lines are decomposed into triangles, we need to be sure
to disable polygon culling, stippling, "un-filled" modes, etc.
This patch sets the rasterization state to disable those things prior to
drawing points/lines with triangles, then restores the previous state
afterward.
The new piglit point-no-line-cull test checks this problem & solution.
|
|
Conflicts:
src/gallium/drivers/nv10/nv10_state.c
src/gallium/drivers/nv20/nv20_state.c
src/gallium/drivers/nv50/nv50_program.c
|
|
This determines if points should be rasterized according to GL point rules
or as normal quads (GL point sprites / d3d points / d3d point sprites).
|
|
Don't need sprite coord origin per coord.
Also, don't need separate sprite enable bit - if all coords have it diabled,
then there are no point sprites (technically, there's a distinction in pre-GL3,
but it only differs in having more leniency in clamping to max size, something
the state tracker would need to handle and the hardware won't bother anyway).
Also, use packed field for the per-coord enables.
All in all, should save 3 dwords in rasterizer state (from 10 down to 7).
|
|
|
|
|
|
The state tracker is responsible for clamping to any graphics API enforced
size min/max limits for both the static point_size setting as well as per
vertex point size (in the vertex shader).
Note that mesa state tracker didn't actually use these values.
|
|
|
