> Because there is some expectation (with the exception of the private > flags) this is state set by the state tracker.
Yes, currently it's this way, but I think that overall, this is suboptimal. For instance, I think that drivers should override the bind flags, setting them to what the resource actually supports. Right now, after creation the bind flags aren't very useful, since they represent an arbitrary subset of what the resource actually supports. For instance, this would allow the driver to decide between using the blitter module or the 2D engine just by checking the bind flags instead of requiring internal flags or duplicated logic, and would allow an arbitrary util module to choose between a fast path that requires the ability to render and a software fallback, even if the state tracker did not anticipate the need to render and thus didn't ask for it. In fact it's quite possible that right now some parts of the codebase might be unnecessarily using fallbacks just because only a few bind flags were specified at creation, even though most resources actually support any kind of operation. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
