| Age | Commit message (Collapse) | Author |
|---|
|
|
|
UNDEFINED_VERTEX_ID is used by draw_pipe_vbuf to decide whether a vertex
has been emitted or not. The non-pipeline pathes do not use it (they
tell the frontend the max vertex count when prepare() is called).
|
|
Triangle strip alternates the front/back orientation of its triangles.
max_vertices was made even so that varray never splitted a triangle
strip at the wrong positions.
It did not work with triangle strips with adjacencies. And it is no
longer relevant with vsplit.
|
|
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.
|
|
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.
|
|
Now we have draw_elements() and draw_arrays() to be consistent with the
pipe_context drawing functions.
|
|
max_index must be observed to prevent crashes due to bad index data.
I've been using this patch for some time without regressions.
Some places, where we use internal vertex buffer, it is not entirely
clear what max_index should be, so passing just ~0 to avoid regressions
for now.
|
|
|
|
Needs testing.
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Also, rename p_tile.[ch] to u_tile.[ch]
|
|
This fixes culling "parity" errors when splitting long tri strips. Splitting
strips into chunks with an odd number of vertices causes front/back-face
orientation to get reversed and upsets culling.
|
|
The final output buffer can't be used to hold intermediate results
as the intermediate vertex size may be greater than the final vertex
size, and in any case the output buffer may be uncached in hw drivers.
|
|
|
|
|
|
|
|
Preserve the vinfo "EMIT_*" format descriptors in the varient key,
and deal with PSIZE directly in each implementation.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
