Am 22.12.18 um 01:21 schrieb Ilia Mirkin: > > > On Fri, Dec 21, 2018, 19:16 Marek Olšák <mar...@gmail.com > <mailto:mar...@gmail.com> wrote: > > > > On Fri, Dec 21, 2018, 6:28 PM Kenneth Graunke <kenn...@whitecape.org > <mailto:kenn...@whitecape.org> wrote: > > That seems like a reasonable interface to me. > > But, I don't think it's backwards compatible. Today, don't state > trackers set index = 0 and expect all 11 to be returned? We could > easily change the in-tree state trackers, but not sure about the > other ones. > > We could always encode the index differently, but at that point, I > wonder if it would be cleaner to just add a new query type like Ilia > suggested. > > Marek, what would you prefer? > > > Backward compatibility is not required. Gallium is not a stable API. > In tree state trackers can be fixed easily. We shouldn't worry too > much about closed source state trackers. > > > Fwiw my take is that while it's fine to change apis around (we do this > all the time), we should avoid causing a loss of functionality just > because no in-tree state tracker uses it. I think having a > forward-looking gallium API greatly facilitated GL 3 and 4 bringup of > gallium drivers, even though there wasn't necessarily an in-tree way to > access all the functionality at the time. > > As long as all the previously accessible functionality remains, I think > we're fine.
Yes, I agree. Certainly it isn't a problem for us to change the supplied index to the query. Although it is usually better if interface changes are not just semantically different, but also syntactically, to avoid surprises - you know there's always just this odd place in the code which for some reason you failed to change, and a compile error is much better than strange failures later (this is of course even more true for out-of-tree state trackers). But this might not always be feasible, keeping the interface nice should take priority. (There's not really any hard rules for gallium interface changes, that's just my take on it.) Roland > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
