[Mesa-dev] [PATCH 2/3] gallium: define the behavior of PIPE_USAGE_* flags properly

[Fredrik Höglund]

On Wednesday 05 February 2014, Marek Olšák wrote:
> On Wed, Feb 5, 2014 at 10:00 PM, Brian Paul <brianp at vmware.com> wrote:
> > On 02/04/2014 04:26 PM, Marek Olšák wrote:
> >>
> >> From: Marek Olšák <marek.olsak at amd.com>
> >>
> >> STATIC will be removed in the following commit.
> >> ---
> >>   src/gallium/docs/source/screen.rst   | 18 ++++++++++++------
> >>   src/gallium/include/pipe/p_defines.h | 13 +++++++------
> >>   2 files changed, 19 insertions(+), 12 deletions(-)
> >>
> >> diff --git a/src/gallium/docs/source/screen.rst
> >> b/src/gallium/docs/source/screen.rst
> >> index c26f98c..5932e3b 100644
> >> --- a/src/gallium/docs/source/screen.rst
> >> +++ b/src/gallium/docs/source/screen.rst
> >> @@ -343,12 +343,18 @@ PIPE_USAGE_*
> >>   ^^^^^^^^^^^^
> >>
> >>   The PIPE_USAGE enums are hints about the expected usage pattern of a
> >> resource.
> >> -
> >> -* ``PIPE_USAGE_DEFAULT``: Expect many uploads to the resource, intermixed
> >> with draws.
> >> -* ``PIPE_USAGE_DYNAMIC``: Expect many uploads to the resource, intermixed
> >> with draws.
> >> -* ``PIPE_USAGE_STATIC``: Same as immutable (?)
> >> -* ``PIPE_USAGE_IMMUTABLE``: Resource will not be changed after first
> >> upload.
> >> -* ``PIPE_USAGE_STREAM``: Upload will be followed by draw, followed by
> >> upload, ...
> >> +Note that drivers must always support read and write CPU access at any
> >> time
> >> +no matter which hint they got.
> >> +
> >> +* ``PIPE_USAGE_DEFAULT``: Optimized for fast GPU access.
> >> +* ``PIPE_USAGE_IMMUTABLE``: Optimized for fast GPU access and the
> >> resource is
> >> +  not expected to be mapped after the first upload.
> >
> >
> > How about "mapped or changed"?  For example, an immutable resource probably
> > shouldn't be the dest of a blit.
> 
> Isn't it too strict? Who would want to have such a strict flag?

It matches D3D11_USAGE_IMMUTABLE.  But the ARB_buffer_storage spec
explicitly says that immutable buffers can be updated with calls such as
glCopyBufferSubData and glClearBuffer.

Fredrik