diff options
author | Marek Olšák <[email protected]> | 2012-05-12 13:08:02 +0200 |
---|---|---|
committer | Marek Olšák <[email protected]> | 2012-05-12 23:13:45 +0200 |
commit | b496136af84e396e7890082817b563dc53ac36fc (patch) | |
tree | 4ea3cc3f6e964e3452c7bbf18ac0b3b4c25e9e18 /src/gallium/include | |
parent | 1a840cc5925f52079916feb2c456816a7a91d627 (diff) |
gallium: remove user_buffer_create from the interface
Nothing uses it now.
Diffstat (limited to 'src/gallium/include')
-rw-r--r-- | src/gallium/include/pipe/p_screen.h | 26 |
1 files changed, 0 insertions, 26 deletions
diff --git a/src/gallium/include/pipe/p_screen.h b/src/gallium/include/pipe/p_screen.h index 7ae7c9a04e1..b4a7f01af66 100644 --- a/src/gallium/include/pipe/p_screen.h +++ b/src/gallium/include/pipe/p_screen.h @@ -162,32 +162,6 @@ struct pipe_screen { /** - * Create a buffer that wraps user-space data. - * - * Effectively this schedules a delayed call to buffer_create - * followed by an upload of the data at *some point in the future*, - * or perhaps never. Basically the allocate/upload is delayed - * until the buffer is actually passed to hardware. - * - * The intention is to provide a quick way to turn regular data - * into a buffer, and secondly to avoid a copy operation if that - * data subsequently turns out to be only accessed by the CPU. - * - * Common example is OpenGL vertex buffers that are subsequently - * processed either by software TNL in the driver or by passing to - * hardware. - * - * XXX: What happens if the delayed call to buffer_create() fails? - * - * Note that ptr may be accessed at any time upto the time when the - * buffer is destroyed, so the data must not be freed before then. - */ - struct pipe_resource *(*user_buffer_create)(struct pipe_screen *screen, - void *ptr, - unsigned bytes, - unsigned bind_flags); - - /** * Do any special operations to ensure frontbuffer contents are * displayed, eg copy fake frontbuffer. * \param winsys_drawable_handle an opaque handle that the calling context |