| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
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.
|
|
Remove lots of old cruft.
|
|
pipe->clear() only used to clear whole buffers (no scissor) w/out masking.
Draw a colored quadrilateral in all other cases.
|
|
git+ssh://brianp@git.freedesktop.org/git/mesa/mesa into softpipe_0_1_branch
|
|
|
|
The one place the functionality continues to be needed is as last-ditch
implementations of TexCopyImage, etc. TBD what to do about that, but
that will be an issue for state_tracker, not for here.
|
|
|
|
|
|
Have added intel_batchbuffer_flush calls to the blit functions. We
still shouldn't be calling back into this remnant intel code from the
softpipe driver, though, so that will go too at some point.
|
|
|
|
Still require the intelClear() call to flush batchbuffers. That will be
removed later...
|
|
|
|
now.
Note: softpipe_clear() should really be renamed to something like
pipe_clear_with_blits() and put into a driver-indepedent module...
|
|
Add a 'mask' param to region_fill() to help with clearing combined Z/stencil buffers, glColorMask, etc.
|
|
|
|
|
|
Each pipe driver will build to a .a library, as these will optionally
be included in the various DRI drivers (this will make more sense once
there is at least one hardware driver...). Not strictly necessary for
softpipe, but want to minimize the differences between it and
actual hw implementations.
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
This is intended to support the softpipe development work. More code
will be removed and pushed into softpipe until this basicially becomes
the DRI/GLX interface for that driver.
|
|
|
|
This fixes a problem hit by glClear in the samples/stencil.c program.
|
|
|
|
|
|
|
|
|
|
Conflicts:
src/mesa/drivers/dri/i915tex/intel_buffers.c
src/mesa/drivers/dri/i915tex/intel_context.c
src/mesa/drivers/dri/i915tex/intel_fbo.c
src/mesa/drivers/dri/i915tex/intel_pixel_draw.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.
|
|
|
|
|
|
|
|
|
|
|
|
Must not change to/from swrast after Render.Start or bad things will happen.
(Driver will still somewhat incorrectly report an implementation error,
and apps can't really figure out if a prog is natively supported as validation
is later - could try doing it earlier to give some hint at least, even though
native status may still change later due to fog etc.)
|
|
into softpipe_0_1_branch
|
|
|
