<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 16, 2016 at 11:25 AM, Rob Clark <span dir="ltr"><<a href="mailto:robdclark@gmail.com" target="_blank">robdclark@gmail.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="">On Tue, Feb 16, 2016 at 1:39 PM, Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote:<br>
> So, we just pushed a branch containing a Vulkan driver.  Naturally, we<br>
> would like to incorporate that driver into the upstream mesa tree.  While<br>
> we work on upstreaming the prerequisites in NIR and the i965 back-end<br>
> compiler, there is a question that needs answering:  Where do we put it?<br>
><br>
> The Vulkan driver challenges the tree-like nature of the way mesa is<br>
> currently organized.  We now have two drivers that share a lot of the same<br>
> underlying hardware-specific code (compiler and ISL) but target different<br>
> APIs and no gallium-like middle layer to hide behind.  Obviously, we don't<br>
> want to put a Vulkan driver in src/mesa/drivers/dri/i965.  If we start a<br>
> src/vulkan directory, we don't really want to put the shared parts into<br>
> src/vulkan/intel.  Where should we put the Intel-specific but API-agnostic<br>
> bits?  In particular, we need a place to put ISL and the back-end compiler.<br>
> We don't want to deal with the headaches of making a public API and keeping<br>
> it stable, so they need to live somewhere in the mesa tree.<br>
><br>
> In my personal opinion, the best thing to do is probably to add a src/intel<br>
> folder with subfolders for vulkan, isl, and the back-end compiler.  The<br>
> src/mesa/drivers/dri/i965 folder would then basically be just the GL bits<br>
> of the driver.  It does seem a little odd to have "intel" as a top-level<br>
> source folder, but I can't come up with anything better.<br>
<br>
</span>Some day (ie. not near-term future) I'd like to share ir3 compiler<br>
backend between vulkan and gallium.. and I think there it is even less<br>
clear how to arrange things.  Perhaps in an ideal world, gl-on-vulkan<br>
could replace gallium / mesa-st.. although I'm not even sure how that<br>
would work.. even if it didn't give up some features/performance, I<br>
have a lot of shared code between adreno generations that can support<br>
vulkan (a4xx, and possibly a5xx) and which can not (a3xx)<br></blockquote><div><br></div><div>I think it's best to assume, for the sake of these discussions, that GL-on-vulkan isn't going to happen, at least not for quite some time.  It's theoretically possible but a lot of work and it's not clear what the performance will be.  For now, GL and Vulkan drivers will likely be separate things (with shared code).<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So not really an answer, more an observation that I'm not really sure<br>
that there is a right answer..<br></blockquote><div><br></div><div>Neither do I/we.  That's why I sent the e-mail. :-)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Thoughts?  Opinions?  Favorite colors?<br>
<br>
blue, no red... arrrgghhh..<br>
<br>
BR,<br>
-R<br>
<br>
> --Jason<br>
><br>
><br>
> _______________________________________________<br>
> mesa-dev mailing list<br>
> <a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a><br>
> <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a><br>
><br>
</blockquote></div><br></div></div>