[Mesa-dev] RFC: enforcing gallium resource bind flags

Marek Olšák maraeo at gmail.com
Fri Mar 1 02:02:18 PST 2013

On Fri, Mar 1, 2013 at 12:31 AM, Roland Scheidegger <sroland at vmware.com> wrote:
> Hi,
> there is some sloppy usage of bind flags in the opengl state tracker
> (that is, resources get used for things which they didn't have the bind
> flag set).
> We'd really like to enforce these flags to be honored but it doesn't
> really work (ok llvmpipe so far would only really care about sampler
> view, color render target, depth/stencil - see also
> c8eb2d0e829d0d2aea6a982620da0d3cfb5982e2).
> Currently it looks like there's at least two issues with those bind
> flags in the opengl state tracker (for these bind flags only, there are
> almost certainly more).
> 1) for textures, the state tracker will always try to allocate resources
> with both sampler_view and render_target (or depth/stencil) bind flags.
> However it will drop these flags for resources where this isn't
> supported. This is all right, however when we try to render to such
> resources, the surface will be created regardless (but it won't get used
> as it will fail framebuffer validation which checks the attachments and
> specifically tests if the format is a renderable format). I guess this
> could be fixed (seems a bit backward, it might be possible to just look
> at the resource bind flags to decide if we create a surface or not, and
> we shouldn't need to check the format later - if we've got the bind flag
> we know we can create a surface and hence render to).
> 2) a far more difficult problem seem to be buffers. While piglit doesn't
> hit it (I modified the tbo test to hit this) it is possible to create
> buffers with any target and later bind to anything. So the state tracker
> has no knowledge at all what a buffer will eventually get used for
> (other than the hint when it was first created), and it seems
> unreasonable to just set all possible bind flags all the time. But then
> still enforcing bind flags later would require the state tracker to
> recreate the resource (with more bind flags) and copy over the old
> contents, which sounds very bad too.
> So any ideas?

In my opinion, the bind flags are useless, because they cannot be
determined for OpenGL resources exactly. The only exceptions are:
- PIPE_BIND_CONSTANT_BUFFER, which is set correctly for the default
non-UBO constant buffer.
- PIPE_BIND_SCANOUT for the DDX and DRM state trackers.

The radeon drivers ignore the bind flags entirely except SCANOUT and
GLOBAL, and r300g also checks for CONSTANT_BUFFER.

The OpenGL buffer API doesn't have any bind flags. It only has binding
points, and any buffer can be bound to any binding point. Textures are
just as fun. You can create a texture or a renderbuffer, but if you
use CopyTexSubImage, the roles are swapped - what was a texture is
suddenly a renderbuffer and what was a renderbuffer is suddenly a

If we didn't need the 3 bind flags mentioned above, I would be for
removing pipe_resource::bind, because it's not that useful.


More information about the mesa-dev mailing list