struct pipe_fence_handle;
struct pipe_winsys;
struct pipe_buffer;
-
+struct pipe_texture;
+struct pipe_surface;
+struct pipe_video_surface;
+struct pipe_transfer;
/**
* Check if the given pipe_format is supported as a texture or
* drawing surface.
* \param tex_usage bitmask of PIPE_TEXTURE_USAGE_*
- * \param flags bitmask of PIPE_TEXTURE_GEOM_*
+ * \param geom_flags bitmask of PIPE_TEXTURE_GEOM_*
*/
boolean (*is_format_supported)( struct pipe_screen *,
enum pipe_format format,
const struct pipe_texture *templat);
/**
- * Create a new texture object, using the given template info, but on top of
+ * Create a new texture object, using the given template info, but on top of
* existing memory.
*
* It is assumed that the buffer data is layed out according to the expected
/**
- * Buffer management. Buffer attributes are mostly fixed over its lifetime.
- *
+ * Create a new buffer.
+ * \param alignment buffer start address alignment in bytes
+ * \param usage bitmask of PIPE_BUFFER_USAGE_x
+ * \param size size in bytes
*/
struct pipe_buffer *(*buffer_create)( struct pipe_screen *screen,
unsigned alignment,
unsigned width, unsigned height,
enum pipe_format format,
unsigned usage,
+ unsigned tex_usage,
unsigned *stride);
/**
* Map a subrange of the buffer data store into the client's address space.
*
- * Return pointer is always relative to offset 0, regardless of the
- * read/write ranges.
+ * The returned pointer is always relative to buffer start, regardless of
+ * the specified range. This is different from the ARB_map_buffer_range
+ * semantics because we don't forbid multiple mappings of the same buffer
+ * (yet).
*/
void *(*buffer_map_range)( struct pipe_screen *screen,
struct pipe_buffer *buf,
unsigned usage);
/**
- * written is the range that the client actually wrote.
+ * Notify a range that was actually written into.
+ *
+ * Can only be used if the buffer was mapped with the
+ * PIPE_BUFFER_USAGE_CPU_WRITE and PIPE_BUFFER_USAGE_FLUSH_EXPLICIT flags
+ * set.
+ *
+ * The range is relative to the buffer start, regardless of the range
+ * specified to buffer_map_range. This is different from the
+ * ARB_map_buffer_range semantics because we don't forbid multiple mappings
+ * of the same buffer (yet).
+ *
*/
void (*buffer_flush_mapped_range)( struct pipe_screen *screen,
struct pipe_buffer *buf,
unsigned offset,
unsigned length);
+ /**
+ * Unmap buffer.
+ *
+ * If the buffer was mapped with PIPE_BUFFER_USAGE_CPU_WRITE flag but not
+ * PIPE_BUFFER_USAGE_FLUSH_EXPLICIT then the pipe driver will
+ * assume that the whole buffer was written. This is mostly for backward
+ * compatibility purposes and may affect performance -- the state tracker
+ * should always specify exactly what got written while the buffer was
+ * mapped.
+ */
void (*buffer_unmap)( struct pipe_screen *screen,
struct pipe_buffer *buf );
void (*buffer_destroy)( struct pipe_buffer *buf );
+ /**
+ * Create a video surface suitable for use as a decoding target by the
+ * driver's pipe_video_context.
+ */
+ struct pipe_video_surface*
+ (*video_surface_create)( struct pipe_screen *screen,
+ enum pipe_video_chroma_format chroma_format,
+ unsigned width, unsigned height );
+
+ void (*video_surface_destroy)( struct pipe_video_surface *vsfc );
+
/**
* Do any special operations to ensure frontbuffer contents are
*/
int (*fence_signalled)( struct pipe_screen *screen,
struct pipe_fence_handle *fence,
- unsigned flag );
+ unsigned flags );
/**
* Wait for the fence to finish.
*/
int (*fence_finish)( struct pipe_screen *screen,
struct pipe_fence_handle *fence,
- unsigned flag );
+ unsigned flags );
};