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

Roland Scheidegger sroland at vmware.com
Thu Feb 28 15:31:56 PST 2013


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?

Roland


More information about the mesa-dev mailing list