| Age | Commit message (Collapse) | Author |
|---|
|
Build a buffer of contigous vertices and indices at the backend of our
software transformation/clipping path. This will become the mechanism
for emitting buffers of vertices to rasterization hardware.
This is similar to but not the same as the post-transform vertex cache.
In particular, these vertices are subject to clipping, culling, poly offset,
etc. The vertices emitted will all be used by hardware.
TODOs include the actual transformation to hardware vertex formats, moving
this out of softpipe to somewhere more useful and allowing >1 primitive to
share the generated VB.
|
|
|
|
Remove/disable the attrib/slot mapping arrays in a few places.
Work in progress...
|
|
|
|
state
|
|
Converting depth and stencil objects into a single state object
(d3d10 like) and making it immutable.
|
|
Switch the sample to be an immutable state object.
|
|
We want our state objects to be immutable, handled via the
create/bind/delete calls instead of struct propagation.
Only implementing the blend state to see how it would look like
and work.
|
|
This replaces the temporary occlusion counter functions we had before.
Added new ctx->Driver.WaitQuery() function which should block until the result is ready.
Sketch out some code for vertex transformation feedback counters.
|
|
|
|
to cpy.
One less dependency on the TGSI_ATTRIB_x flags.
This requires setting the vertex_info->interp_mode[] values in the i915 driver and passing them to draw_set_vertex_attributes().
|
|
|
|
They're now totally independent of the actual shaders.
Also, implemented in terms of pipe_buffer_handles/objects.
|
|
We weren't mapping all the needed vertex array buffers.
Move array state that was temporarily in draw_context to softpipe_context.
Remove a bunch of dead code.
|
|
Renamed pipe_fs_state to pipe_shader_state since it can be used for both
vertex and fragment shader info.
|
|
|
|
|
|
Mainly down to the support for legacy TNL processing now.
|
|
|
|
This interface is defined by softpipe and any window system (eg i915pipe)
wishing to use softpipe is required to implement the interface.
Currently the interface is all about buffer management.
Generalizing, each pipe driver will advertise an interface in a similar
spirit to this, and again any window system driver wishing to use that
rendering pipeline will have to implement the interface it defines. It
clearly isn't a one-way street however, as softpipe could just do its own
buffer management with malloc. The interaction with a buffer manager is
desired to allow us to exercise the hardware swapbuffers functionality of
the i915pipe driver, and also to get a feel for the way hardware drivers
which really need a buffer manager will work.
|
|
The cliprect depends on the scissor rect (if enabled), otherwise the drawing
surface bounds.
|
|
Also added draw_stage::reset_line_stipple(). There may be a better way
of doing that though.
|
|
|
|
|
|
This removes the notion of multiple color buffers from all other stages.
Will need a bit more work when shaders with multiple render targets arrive.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
in some structs
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
(fragment ops).
This is very much like the clipper/setup pipeline for primitives.
|
|
|
|
|
|
We should be able to render to any depth/format of X window now.
|
|
|
|
|
|
|
|
softpipe/state_tracker --> state_tracker/
softpipe/ --> pipe/
softpipe/generic --> pipe/softpipe/
I don't think pipe is a great name, but I disliked all the others too.
Luckily it's fairly easy to rename with git, so this can be revisited
later.
|
