| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Connect intel_i915_batch_finish() into i915_winsys, just like intel_i915_batch_flush().
Call i915_winsys->batch_finish() in response to pipe->flush(PIPE_FLUSH_WAIT).
Now all the batchbuffer/fence code is in one place and a little cleaner.
|
|
The winsys object is now per-screen and shared by multiple contexts.
The regionPool is now part of the i915 winsys layer.
The winsys wait_idle() and flush_frontbuffer() funcs will get more attention...
|
|
|
|
|
|
|
|
|
|
pipe_surface now has a pointer to the winsys which create/owns the surface.
This allows clean surface deallocation w/out a rendering context.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fixes failed assertion in glxgears.
|
|
Winsys driver needs some hints in order to allocate the appropriate kind of
memory for the buffer.
|
|
|
|
XMesaContext has an st_context * which contains a mesa context.
|
|
intelCopyBuffer() is now intelDisplayBuffer(): it displays the given surface
in the on-screen window.
Added a pipe_surface parameter to winsys->flush_frontbuffer().
Front buffer rendering/flushing actually works now.
But, we should only allocate the front surface on demand...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Plug xmesa_is_format_supported() into the softpipe_winsys object.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
