GL 3.0 (EXT_draw_buffers2) and other APIs allow independent blend enables and
write masks per render target, ARB_draw_buffers_blend (and other APIs) also
allow independent blend functions. Things like dithering, logic ops however
are not extended to be per rendertarget, that might be conceptually possible
however it doesn't look like any API wants to expose this.
This is part of the GL_EXT_draw_buffers2 extension and part of GL 3.0.
The ctx->Color.ColorMask field is now a 2-D array. Until drivers are
modified to support per-buffer color masking, they can just look at
the 0th color mask.
The new _mesa_ColorMaskIndexed() function will be called by
glColorMaskIndexedEXT() or glColorMaski().
_ActualFormat is replaced by Format (MESA_FORMAT_x).
ColorEncoding, ComponentType, RedBits, GreenBits, BlueBits, etc. are
all replaced by MESA_FORMAT_x queries.
Currently using max_slots > 1 will cause synchronous rendering
if the driver flushes its command buffers between one bitmap and the
next.
Need to improve buffer_write to allow NO_WAIT (as well as no_flush)
updates to buffers where we know there is no conflict with previous
data.
There are two usage types of buffer CPU accesses:
One where we try to use the buffer contents for multiple draw commands in
a batch. (batch := sequence of commands that are flushed together),
like incrementally adding bitmaps to a bitmap texture that is reallocated
on flush.
And one where we assume we can safely overwrite the old buffer contexts, like
glTexSubImage. In this case we need to make sure all old drawing commands
referencing the buffer are flushed before we map the buffer.
This is easily forgotten.
Add wrappers for the most common of these operations. The first type is
prefixed with "st_no_flush" and the second type is prefixed with
"st_cond_flush", where "cond" indicates that we attmpt to only flush
if there is indeed unflushed draw commands referencing the buffer.
Prefixed functions are
screen::get_tex_transfer
pipe_buffer_write
pipe_buffer_read
pipe_buffer_map
Please use the wrappers whenever possible.
Signed-off-by: Thomas Hellstrom <thellstrom-at-vmware-dot-com>
The draw module provides a similar interface to the driver which
is retained as various bits of hardware may be able to take on
incremental parts of the vertex pipeline. However, there's no
need to advertise all this complexity to the state tracker.
There are basically two modes now - normal and passthrough/screen-coords.
Any driver who needs a copy of the shader tokens must organize to
do so itself. This has been the case for a long time, but there
was still defensive code in the state tracker, which is now removed.
Any bugs resulting from this need to be fixed in the offending driver...
The core reference counting code is centralized in p_refcnt.h.
This has some consequences related to struct pipe_buffer:
* The screen member of struct pipe_buffer must be initialized, or
pipe_buffer_reference() will crash trying to destroy a buffer with reference
count 0. u_simple_screen takes care of this, but I may have missed some of
the drivers not using it.
* Except for rare exceptions deep in winsys code, buffers must always be
allocated via pipe_buffer_create() or via screen->*buffer_create() rather
than via winsys->*buffer_create().
Quite a few util modules were maintaining a single vertex buffer over multiple
frames, and potentially reusing it in subsequent frames. Unfortunately that
would force us into syncrhonous rendering as the buffer manager would be
forced to wait for the previous rendering to complete prior to allowing the
map.
This resolves that issue, but requires the state tracker to issue a few new
flush() calls at the end of each frame.
