| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
Also, rename p_tile.[ch] to u_tile.[ch]
|
|
If the user called glDrawArrays(GL_TRIANGLES, count=1), trim() returned a
very large integer because of the unsigned arithmetic.
|
|
debug_get_bool_option will interpret "n", "no", "0", "f", or
"false" as FALSE; and everything else as TRUE. The default value
(used when the variable is not set) is received as a parameter.
|
|
|
|
|
|
|
|
The code is now living in it's intended place as a pt middle end.
|
|
Also add some util functions in pt_util.c
|
|
- drop support for running the pipeline (ie. don't populate the flags values)
- pass through all split-able primitives intact to the middle end
- only primitives that can't be split are shunted on the draw-element path
|
|
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.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
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.
|
