<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Dec 21, 2018, 19:16 Marek Olšák <<a href="mailto:maraeo@gmail.com">maraeo@gmail.com</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Dec 21, 2018, 6:28 PM Kenneth Graunke <<a href="mailto:kenneth@whitecape.org" target="_blank" rel="noreferrer">kenneth@whitecape.org</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That seems like a reasonable interface to me.<br>
<br>
But, I don't think it's backwards compatible.  Today, don't state<br>
trackers set index = 0 and expect all 11 to be returned?  We could<br>
easily change the in-tree state trackers, but not sure about the<br>
other ones.<br>
<br>
We could always encode the index differently, but at that point, I<br>
wonder if it would be cleaner to just add a new query type like Ilia<br>
suggested.<br>
<br>
Marek, what would you prefer?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">As long as all the previously accessible functionality remains, I think we're fine.</div><div dir="auto"></div></div>