Age | Commit message (Collapse) | Author |
|
|
|
Still need to produce decl instructions for vertex shaders...
|
|
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.
|
|
This is a step toward removing TGSI_ATTRIB_ tokens.
Basically, when translating Mesa programs to TGSI programs, pass in input and
output register re-maps, plus interpolation info.
There's some known breakage (cubemap.c) so more to be done...
|
|
state
|
|
Converting depth and stencil objects into a single state object
(d3d10 like) and making it immutable.
|
|
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
|
|
|
|
Replace VF_ATTRIB_x with TGSI_ATTRIB_x
When converting mesa programs to TGSI programs, also convert the InputsRead
and OutputsWritten to a mask of TGSI_ATTRIB_ bits.
Still need to do conversion for vertex programs...
|
|
|
|
They're now totally independent of the actual shaders.
Also, implemented in terms of pipe_buffer_handles/objects.
|
|
|
|
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.
|
|
|
|
|
|
|
|
Remove surface ptr from gl_renderbuffer.
Use st_renderbuffer in most places.
More clean-up.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
Also some minor clear fixes.
|
|
|
|
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
|
|
Z testing now works with i915 driver.
Add gl_renderbuffer::surface pointer (and reverse pointer).
Remove intel_surface and xmesa_surface types - no longer used.
|
|
|
|
Handling of constants might change. For now, the st_fragment_program struct
contains a pipe_constant_buffer (not a pointer).
|
|
Not sure the generated program looks correct though...
|
|
|
|
|
|
|
|
|
|
of [1,256].
|
|
in some structs
|
|
|
|
|
|
|
|
|
|
|
|
|