<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 10, 2018 at 4:44 PM, Gert Wollny <span dir="ltr"><<a href="mailto:gert.wollny@collabora.com" target="_blank">gert.wollny@collabora.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Am Dienstag, den 10.07.2018, 09:19 +1000 schrieb Dave Airlie:<br>
> <br>
> Just FYI in future please don't push mesa patches until the renderer<br>
> side patch has landed, this is to avoid the abi accidentally<br>
> diverging around the caps.<br>
</span>Sure, I'll keep that in mind, and sorry for rushing to push this. <br>
<br>
However, this actually points to a bigger problem: Given that the<br>
mesa/virgl driver is completely separate from the host virglrenderer,<br>
how do we ensure in a real world application that host and guest agree<br>
on the abi? There is this 'version' in the<br>
vrend_renderer_fill_caps_<wbr>common and the 'max_version' in the caps, but<br>
the first one is not used at all, and the second is not used beyond<br>
signalling the availability of caps set 2. Maybe we should define some<br>
algorithm to bump that latter number so the client can see what values<br>
in the caps were actually filled by the host? <br>
<br></blockquote><div><br></div><div>We already deal with ABI at runtime. The problem is diverging the virgl_hw.h file.</div><div><br></div><div>One copy of that file needs to be master and we only add to the end of the caps v2</div><div>struct, but the version that is the master copy is the one in virglrenderer. So if <br></div><div>we end up pushing patches to mesa first, and someone pushes another change</div><div>to virglrenderer we get incompatible overlap.</div><div><br></div>Dave.</div><div class="gmail_quote"><br></div></div></div>