| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Return GL_FALSE if we failed to allocate the buffer. Then raise
GL_OUT_OF_MEMORY in core Mesa.
|
|
This fixes a bunch of gallium regressions since
commit 8096aa521369c3bcf5226c060efa6dd06e48ddc8
|
|
Conflicts:
src/mesa/vbo/vbo_exec_draw.c
|
|
As prescribed by ARB_map_buffer_range.
|
|
These functions may be called from the VBO code (not just user GL calls)
so do some parameter sanity checking.
|
|
Just use the gl_buffer_object::Size field. Remove unnecessary size/offset
error checks. Core Mesa will have already done these checks before these
functions are called.
|
|
In st_bufferobj_map_range(), set obj->Offset consistently with its
usage elsewhere.
|
|
Conflicts:
Makefile
src/mesa/main/version.h
src/mesa/shader/slang/slang_preprocess.c
src/mesa/state_tracker/st_cb_bufferobjects.c
|
|
|
|
|
|
|
|
|
|
|
|
This needs a proper fix to propogate the out-of-memory condition back
up to Mesa and the app as a GL error. Until then, at least catch the
problem at its source.
|
|
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>
|
|
Also implement context member functions to optimize away those
flushes whenever possible.
Signed-off-by: Thomas Hellstrom <thellstrom-at-vmware-dot-com>
|
|
Namelly, FlushMappedBufferRange takes a subrange relative to the original
range.
|
|
|
|
|
|
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().
|
|
|
|
Conflicts:
scons/gallium.py
src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
src/gallium/include/pipe/p_defines.h
src/mesa/vbo/vbo_exec_api.c
src/mesa/vbo/vbo_exec_draw.c
|
|
Using PIPE_BUFFER_USAGE_DONTBLOCK.
|
|
Saves code, and will simplify future interface changes.
|
|
|
|
Use _mesa_malloc(), _mesa_free(), etc everywhere, not malloc(), free(), etc.
Still using CALLOC_STRUCT() at this point.
|
|
We want to use the pipe_buffer_* inlines everywhere, but a pipe context
is not always available nor is it needed.
|
|
This allows us to remove most of the direct references to winsys in the state tracker.
|
|
Provide an actual definition of the pipe_buffer struct, containing
the parameters used to create the buffer, and its refcount.
Shift refcounting buffers out of the winsys interface, similar to
surfaces & textures.
Rework pipebuffer/ to reflect the fact these changes, and also Michel's
reworking of the buffer interface.
|
|
The properties of a buffer represented by struct pipe_buffer_handle are now
basically constant over its lifetime. The state tracker gets to deal with any
more complex buffer semantics it may need to provide.
|
|
|
|
Winsys driver needs some hints in order to allocate the appropriate kind of
memory for the buffer.
|
|
|
|
|
|
|
|
|
|
We need to do these initializations before initializing the Mesa context
because context init involves creating texture/program/etc objects.
|
|
The state_tracker driver needs these to implement, eg. pixel buffer objects,
vertex buffer objects.
|
