| Age | Commit message (Collapse) | Author |
|---|
|
|
|
They have been deprecated by vsplit.
|
|
vsplit is based on varray. It sets the split flags when a primitive is
splitted. It also has support for indexed primitives.
For indexed primitives, unlike vcache, vsplit splits the primitives
instead of decomposes them.
|
|
draw_pt_trim_count is renamed from trim in draw_pt.c.
|
|
The run method is simplified to take the start vertex and the vertex
count.
|
|
Update the middle end interface to pass the primitive flags from the
frontends to the pipeline. No frontend sets the flags yet.
|
|
We were previously calculating a value which was either the geometry
shader output primitive or the application's input primitive, and
passing that to the various front/middle/back components for use as
the ultimate rendering primtive.
Unfortunately, this was not correct -- if the vcache decomposition
path is active and geometry shaders are *not* active, we can end up
with a third primitive -- specifically the decomposed version of the
input primitive.
Rather than trying to precalculate this, just let the individual
components inform their successors about which primitive type they are
recieving.
|
|
register masks, multiple output buffers, multiple primitives,
non-linear vertices (elts) and stride semantics.
|
|
Keith came up with a new way of running the pipeline which involves passing
a few info structs around (for fetch, vertices and prims) and allows us
to correctly handle cases where we endup with multiple primitives generated
by the pipeline itself.
|
|
|
|
of vertices
lots and lots of fixes for geometry shaders. in particular now we work when the gs
emits a different primitive than the one the pipeline was started with and also
we work when gs emits more vertices than would fit in the original buffer.
|
|
interface wise we have everything needed by d3d10 and gl transform feedback.
the draw module misses implementation of some corner cases (e.g. when stream
output wants different number of components per output than normal rendering
paths)
|
|
|
|
code generate big chunks of the vertex pipeline in order to speed up
software vertex processing.
|
|
It's all screaming for integer support -- fake it with float for now.
|
|
fixes, cleanups, etc.
not working yet
|
|
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.
|
|
Previously draw module asked for a pointer into (mapped) vertex data,
which it would incrementally fill and emit draw commands against. This
was hard for the drivers to deal with, especially in the case where a
draw command would force a flush and thus an unmap of the vertex data.
With this change, the draw module explicitly maps & then unmaps vertex
data prior to emitting draw commands.
|
|
|
|
|
|
|
|
The code is now living in it's intended place as a pt middle end.
|
|
Also add some util functions in pt_util.c
|
|
Enable with TEST_FSE=t. Performs fetch from API-provided vertex buffers,
transformation with one of three (two working) hard-coded shaders, and
final emit to hardware vertices all in a single pass.
Currently only really useful for profiling in conjunction with SP_NO_RAST=t.
|
|
|
|
|
|
|
|
|
|
This state is effectively private to the vertex processing part
of the draw module.
|
|
|
|
|
|
|
|
This will at least allow us to make the initial gains to get decent
vertex performance much more quickly & with higher confidence of getting
it right.
At some later point can look again at code-generating all the
fetch/cliptest/viewport extras in the same block as the vertex shader.
For now, just need to get some decent baseline performance.
|
|
|
|
|
|
|
|
Encode edgeflags (and reset_stipple info) into the top two bits of the
fetch elements. This info could be moved elsewhere, but for now we
can live with a 1<<30 maximum element size...
Also use the primitive decomposition code from draw_prim.c verbatim, as
it includes all this stuff and is known to work.
|
|
This handles the case where bypass_vs is set, but vertices need to go
through the pipeline for some reason - eg unfilled polygon mode.
Demonstrates how to drive the pipeline from inside one of these things.
|
|
Leaving it until 'run' is bad as the primitive is pretty much state
for some drivers and so needs to get set early. In some drivers
this is used to determine things like vertex format, etc -- by the
time we get to 'run', it's too late to change this.
|
|
- Reduce the number of changes to the normal vertex ordering
- Assume that the hardware knows how to do this in the standard case.
- Add support to the passthrough vcache path.
|
|
|
|
|
|
Middle-end elements are ushort, but prior to that have to treat all
elements as unsigned to avoid wrapping and/or overruns.
|
|
Trying to put a structure in place that we can actually optimize.
Initially just implementing a passthrough mode, this will fairly soon
replace all the vertex_cache/prim_queue/shader_queue stuff that's so
hard to understand...
Split the vertex processing into a couple of distinct stages:
- Frontend
- Prepares two lists of elements (fetch and draw) to be processed
by the next stage. This stage doesn't fetch or draw vertices, but
makes the decision which to draw. Multiple implementations of this
will implement different strategies, currently just a vcache
implementation.
- MiddleEnd
- Takes the list of fetch elements, fetches them, runs the vertex
shader, cliptest, viewport transform on them to produce a
linear array of vertex_header vertices.
- Passes that list of vertices, plus the draw_elements (which index
into that list) onto the backend
- Backend
- Either the existing primitive/clipping pipeline, or the vbuf_render
hardware backend provided by the driver.
Currently, the middle-end is the old passthrough code, and it build hardware
vertices, not vertex_header vertices as above. It may be that passthrough
is a special case in this respect.
|
