Age | Commit message (Collapse) | Author |
|
TGSI_ATTRIB_x tokens still present and used in a few places.
Expanded set of TGSI_SEMANTIC_x tokens for describing the meaning
of inputs/outputs. These tokens are in a crude state ATM.
Lots of #if 0 / disabled code to be removed yet, etc...
Softpipe and i915 drivers should be in working condition but not heavily tested.
|
|
Basically make cso hold the driver specific struct, while
managing the template.
|
|
Drivers can now create whatever they want from the state template. We
use cso_state object to store the template (necessary during lookups),
and the driver data. Convert blend state to the new semantics.
|
|
Create/Delete calls should be split since in create we'll be
compiling them so we want to know which one it is (vertex/fragment).
|
|
|
|
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 is already handled by the semanics of map(), etc.
|
|
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.
|
|
|
|
This will be used for:
GL_NV_transform_feedback, or similar GL3 functionality
glRasterPos
GL selection/feedback modes
|
|
Now dereferences the old object first.
Target object may be NULL to clear the pointer.
|
|
They're now totally independent of the actual shaders.
Also, implemented in terms of pipe_buffer_handles/objects.
|
|
Creates a new pipe driver that feeds commands to either a hardware or
software pipe depending on fallback state.
Untested concept checkpoint. At this point it compiles.
|
|
|
|
|
|
Renamed pipe_fs_state to pipe_shader_state since it can be used for both
vertex and fragment shader info.
|
|
|
|
|
|
Not currently used.
|
|
Pipe drivers shouldn't really know much about mesa and certainly shouldn't
be #including files from src/mesa/main and the like.
I've also (in i915simple especially) moved over from GL types to
more conventional int/unsigned usage. This probably isn't really the
ultimate desired set of types to use - possibly C99 would be better. It
may even be that a subset of the GL types is preferable.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Not sure if finish() is the right interface yet.
|
|
|
|
|
|
pipe_mipmap_tree and move some code)
|
|
The state_tracker driver needs these to implement, eg. pixel buffer objects,
vertex buffer objects.
|
|
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 frontbuffer/driBufMgr interactions are handled as a special case
in the intel_screen code.
|
|
|
|
pipe->clear() only used to clear whole buffers (no scissor) w/out masking.
Draw a colored quadrilateral in all other cases.
|
|
for glClear.
|
|
Also some minor clear fixes.
|
|
|
|
Add a 'mask' param to region_fill() to help with clearing combined Z/stencil buffers, glColorMask, etc.
|
|
|
|
struct pipe_buffer goes away.
Added basic region functions to softpipe to allocate/release malloc'd regions.
Surface-related code is fairly coherent now.
|
|
Some of these functions probably should be driver-private.
Note: intel_buffer_object is in p_state.h and should be fixed/removed.
There are just a few i915 dependencies in intel_region.c
|
|
|
|
|
|
in some structs
|
|
|
|
|