| Age | Commit message (Collapse) | Author |
|---|
|
The frontbuffer/driBufMgr interactions are handled as a special case
in the intel_screen code.
|
|
Remove lots of old cruft.
|
|
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
|
|
The clamping for these values depends on whether we're drawing AA or non-AA
points, lines. Defer clamping until drawing time. Drivers could compute and
keep clamped AA and clamped non-AA values if desired.
|
|
|
|
|
|
|
|
Make sure that we bind the right buffer (draw or read) when rebinding
the window framebuffer (the api doesn't allow binding different draw and
read buffers at the same time, but the default window framebuffer is basically
2 fb objects, one for read, one for write, which can be different). Pass both
of these two down the driver api (no driver uses this right now).
|
|
xdemos/shape)
|
|
remove some already ifdefed out, no longer functional and used code.
Don't do our own scissor clipping in the pixeldraw/copy paths,
as meas already does that for us...
|
|
|
|
manywin got broken (when intelPageflip got no longer called).
Make sure that intelFlush is getting called when a context gets unbound,
to handle later swapbuffer calls on that context's drawable better.
Related, fix non-current cliprects getting used on unbound drawables.
|
|
|
|
Construct the vertprog instruction in the 4 DWORD parts...
DWORD 0: Opcode and Output.
DWORD 1: First Argument.
DWORD 2: Second Argument.
DWORD 3: Third Argument.
Allow the opcode translation functions to generate more than one instruction;
useful for when an instruction must be emulated. FLR, XPD, etc.
|
|
|
|
|
|
|
