| Age | Commit message (Collapse) | Author |
|---|
|
Plumb the constant buffer sizes down into the tgsi interpreter where
we can do bounds checking. Optional debug code warns upon out-of-bounds
reading. Plus add a few other assertions in the TGSI interpreter.
|
|
|
|
|
|
|
|
aka transform feedback
|
|
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.
|
|
Prevents the assertion failure.
|
|
New draw API function to indicate whether or not to convert points to
quads for sprite rasterization.
Fix point-to-quad conversion regression in the wide-point stage. We
need to check the pipe_rasterizer_state::point_quad_rasterization flag.
|
|
|
|
|
|
use just one constructor to figure out whether to use llvm.
|
|
|
|
Conflicts:
src/gallium/auxiliary/draw/draw_context.c
src/gallium/auxiliary/draw/draw_pipe_aaline.c
src/gallium/drivers/llvmpipe/lp_context.c
|
|
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.
|
|
|
|
|
|
code generate big chunks of the vertex pipeline in order to speed up
software vertex processing.
|
|
Needs testing.
|
|
|
|
Try to avoid future confusion between different, but similar functions.
|
|
|
|
|
|
|
|
Conflicts:
src/gallium/auxiliary/draw/draw_context.c
src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline.c
src/gallium/auxiliary/pipebuffer/Makefile
src/gallium/auxiliary/pipebuffer/SConscript
src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
src/gallium/auxiliary/tgsi/tgsi_scan.c
src/gallium/drivers/i915/i915_surface.c
src/gallium/drivers/i915/i915_texture.c
src/gallium/drivers/llvmpipe/lp_setup.c
src/gallium/drivers/llvmpipe/lp_tex_sample_c.c
src/gallium/drivers/llvmpipe/lp_texture.c
src/gallium/drivers/softpipe/sp_prim_vbuf.c
src/gallium/state_trackers/xorg/xorg_dri2.c
src/gallium/winsys/drm/intel/gem/intel_drm_api.c
src/gallium/winsys/drm/nouveau/drm/nouveau_drm_api.c
src/gallium/winsys/drm/radeon/core/radeon_drm.c
src/gallium/winsys/drm/vmware/core/vmw_screen_dri.c
src/mesa/state_tracker/st_cb_clear.c
|
|
|
|
|
|
|
|
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).
|
|
The draw module provides a similar interface to the driver which
is retained as various bits of hardware may be able to take on
incremental parts of the vertex pipeline. However, there's no
need to advertise all this complexity to the state tracker.
There are basically two modes now - normal and passthrough/screen-coords.
|
|
|
|
|
|
The Minimum Resolvable Depth factor depends on the driver and can't just
be computed from the number of Z buffer bits.
Glean's polygon offset test now passes with softpipe.
Still need to determine the MRD factor for other gallium drivers, if they use
the draw module's polygon offset stage...
|
|
|
|
vertex shaders
This may only be practical for the softpipe driver at this time.
|
|
|
|
|
|
Also, rename p_tile.[ch] to u_tile.[ch]
|
|
|
|
|
|
|
|
|
|
When flushing/rendering, some stages (like AA line/point) need to set
pipe/driver state. Those driver functions often call draw_flush().
That leads to recursion.
Use new draw->suspend_flush flag to explicitly prevent that in the key places.
Remove the draw->vcache_flushing field.
Reuse draw->flushing as a debug/assertion var.
|
|
Fixes broken polygon stipple, aaline, aapoint stages
|
|
|
|
Also, provide a separate flag to say whether the driver can handle
clipping/rhw tasks, in addition to the API flag which indicates they
have already been done.
|
|
|
|
This state is effectively private to the vertex processing part
of the draw module.
|
|
|
|
|
|
|
