| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
