| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
Which are slightly different from ARB_map_buffer_range semantics, since
gallium still supports more than one mapping of the same buffer.
|
| |
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | |
| | |
| | |
| | | |
To prevent blocking when mapping a buffer.
|
| | |
| | |
| | |
| | | |
(cherry picked from commit 434e255eae90b0f3d836d452b7d3b0c5aadf78b8)
|
| | | |
|
|\| | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
BSD supports pipe in the same way as linux hence options which
are safe for linux are also safe for BSD. Define PIPE_OS_BSD in
include/pipe/p_config.h and adjust the defines to make use of it.
Also define MAP_ANONYMOUS for BSD systems which use MAP_ANON
Signed-off-by: Benjamin Close <[email protected]>
|
| | | |
|
|/ /
| |
| |
| |
| |
| |
| | |
map/unmap.
This allows the pipe driver to do more efficient DMA upload/downloads, by
avoiding to read/write unneeded/unmodified data.
|
| |
| |
| |
| | |
Saves code, and will simplify future interface changes.
|
| | |
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | |
| | | |
Conflicts:
src/gallium/drivers/softpipe/sp_tile_cache.c
|
| |\ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
src/mesa/state_tracker/st_cb_accum.c
src/mesa/state_tracker/st_cb_drawpixels.c
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Instead, a new pipe_transfer object has to be created and mapped for
transferring data between the CPU and a texture. This gives the driver more
flexibility for textures in address spaces that aren't CPU accessible.
This is a first pass; softpipe/xlib builds and runs glxgears, but it only shows
a black window. Looks like something's off related to the Z buffer, so the
depth test always fails.
|
| |/ /
|/| |
| | |
| | |
| | | |
The debug functions depend on several util function for os abstractions, and
these depend on debug functions, so a seperate module is not possible.
|
| | |
| | |
| | |
| | |
| | | |
Driver writers often got confused and assumed Size to be
the number of immediate values in Immediate declaration.
|
| | | |
|
|/ /
| |
| |
| | |
Not used in p_state.h but used in p_context.h and p_screen.h
|
| |
| |
| |
| |
| |
| |
| | |
this change disassociates, at least from the driver perspective,
the surface from buffer. surfaces are technically now views on the
textures so make it so by hiding the buffer in the internals of
textures.
|
| |
| |
| |
| | |
forwards screen calls to the winsys
|
| |
| |
| |
| |
| | |
move it to pipe/internal/p_winsys_screen.h and start converting
the state trackers to the screen usage
|
| |
| |
| |
| |
| |
| | |
allows the driver to overwrite buffer allocation, first step on the way
to making winsys interface internal to the drivers. state trackers and
the code above it will go through the screen
|
| |
| |
| |
| | |
reuse the size of the actual buffer
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit is mostly just a cosmetic change that cleans-up the interfaces,
replacing pipe_winsys::surface_* calls by
/**
* Allocate storage for a display target surface.
*
* Often surfaces which are meant to be blitted to the front screen (i.e.,
* display targets) must be allocated with special characteristics, memory
* pools, or obtained directly from the windowing system.
*
* This callback is invoked by the pipe_screenwhen creating a texture marked
* with the PIPE_TEXTURE_USAGE_DISPLAY_TARGET flag to get the underlying
* buffer storage.
*/
struct pipe_buffer *(*surface_buffer_create)(struct pipe_winsys *ws,
unsigned width, unsigned height,
enum pipe_format format,
unsigned usage,
unsigned *stride);
Most drivers were updated but not all were tested. Use the softpipe pipe
driver and the xlib winsys changes as a reference when fixing other drivers.
|
| | |
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | | |
When passed to map() signals that the buffer's previous contents are
not required, allowing the driver to allocate a new buffer if the
current buffer can not be mapped immediately.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This works on top Gallium and KMS. The only thing that
does not work currently is swap buffers for shown mesa
screens. So the only fun thing this will produce is a
white screen.
The driver wishing to us the state_tracker needs to
implement the intrace as define in drm_api.h located
in gallium/include/state_tracker. And also have a
working KMS implementation.
|
|/ / |
|
| |
| |
| |
| |
| | |
Knowing how the client intends to use the texture will give the
driver the opportunity to optimize for such cases.
|
| |
| |
| |
| |
| | |
uint64 is not (so?) standard, and often redefined by third parties,
causing name clashes.
|
| |
| |
| |
| | |
INLINE is commonly used in third-party headers.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
add some more srgb texture formats, including compressed ones
various fixes relating to srgb formats
issues: the util code for generating mipmaps will not handle srgb formats
correctly (would need to use a linear->srgb conversion shader)
|
| | |
|