<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 16, 2016 at 11:41 PM, Iago Toral <span dir="ltr"><<a href="mailto:itoral@igalia.com" target="_blank">itoral@igalia.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey Jason,<br>
<br>
this is awesome news, congrats to all the people involved!<br></blockquote><div><br></div><div>Thanks!<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Did you have a chance to try the new driver with anything other than<br>
conformance tests or small demos? I know it is still in a very early<br>
stage but I'd like to know your impressions about how much of an<br>
improvement it brings over the GL driver in its current form and whether<br>
there is still major optimization work to be done. I figure that since<br>
you are using NIR and the same compiler backend used for GL things<br>
should be looking pretty good already.<br></blockquote><div><br></div><div>We have had early access to a few apps. I've almost got dota2 working (still fighting a rendering corruption), but the driver seems to be working pretty well. I think we're doing pretty good on the stability front, but driver isn't quite up to the same performance standards as the GL driver. Not a problem with Vulkan, more that this is a new driver and we haven't had time to do everything yet.<br><br></div><div>What's left to be done? Well, there are some hardware optimizations we haven't turned on yet such as HiZ. There are also a few compiler things that need to be done. The one big gaping hole is that NIR doesn't have loop unrolling yet. Thomas Helland was working on that over the summer but his time was divided between loop unrolling and range analysis and so it never got finished.<br></div><div>--Jason<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
Iago<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Tue, 2016-02-16 at 07:19 -0800, Jason Ekstrand wrote:<br>
> The Intel mesa team is pleased to announce a brand-new open-source<br>
> Vulkan<br>
> driver for Intel hardware. We've been working hard on this over the<br>
> course<br>
> of the past year or so and are excited to finally share it with the<br>
> community. We will work on up-streaming the driver in the next few<br>
> weeks<br>
> and hope to have it all in place in time for mesa 11.3 (mesa 12?). In<br>
> the<br>
> mean time, the driver can be found in the "vulkan" branch of the mesa<br>
> git<br>
> repo on <a href="http://freedesktop.org" rel="noreferrer" target="_blank">freedesktop.org</a>:<br>
><br>
> <a href="https://cgit.freedesktop.org/mesa/mesa/log/?h=vulkan" rel="noreferrer" target="_blank">https://cgit.freedesktop.org/mesa/mesa/log/?h=vulkan</a><br>
><br>
> More information on building the driver and running a few simple apps<br>
> can<br>
> be found on the <a href="http://01.org" rel="noreferrer" target="_blank">01.org</a> web site:<br>
><br>
> <a href="https://01.org/linuxgraphics/blogs/jekstrand/2016/open-source-vulkan-drivers-intel-hardware" rel="noreferrer" target="_blank">https://01.org/linuxgraphics/blogs/jekstrand/2016/open-source-vulkan-drivers-intel-hardware</a><br>
><br>
> We have talked to people at Red Hat and Cannonical and binaries should<br>
> be<br>
> available for Fedora and Ubuntu soon. We will update the page on<br>
> <a href="http://01.org" rel="noreferrer" target="_blank">01.org</a><br>
> with links as soon as they are available.<br>
><br>
> We have also created a small test suite called crucible which contains<br>
> a<br>
> few hundred tests (mostly for miptrees) that we created when bringing<br>
> up<br>
> the driver. This isn't really intended to be the piglit of vulkan.<br>
> With<br>
> the CTS being publicly available, most cross-platform tests should go<br>
> there. We mostly made crucible so that we could write a few tests<br>
> early on<br>
> to get us going and for tests that were targetted specifically at our<br>
> implementation. None the less, they may prove useful to someone and<br>
> we are<br>
> happy to share them. The crucible source code can be found at<br>
><br>
> <a href="https://cgit.freedesktop.org/mesa/crucible/" rel="noreferrer" target="_blank">https://cgit.freedesktop.org/mesa/crucible/</a><br>
><br>
> Frequently Asked Questions:<br>
><br>
> What all hardware does it support?<br>
><br>
> The driver currently supports Sky Lake all the way back to Ivy<br>
> Bridge.<br>
> The driver is Vulkan 1.0 conformant for 64-bit builds on Sky Lake,<br>
> Broadwell, and Braswell. We are still having a couple of 32-bit<br>
> issues<br>
> and support for Haswell, Ivy Bridge, and Bay Trail should be<br>
> considered<br>
> experimental.<br>
><br>
> How much code is shared between the Vulkan and GL drivers?<br>
><br>
> For shaders, we're using a SPIR-V to NIR pass which is new, and a<br>
> few<br>
> new NIR lowering passes for things that we previously depended on<br>
> GLSL<br>
> IR to handle. Beyond that, we're using the same core NIR and the<br>
> same<br>
> back-end compiler that we have for GL. We're carrying a few<br>
> patches<br>
> against the back-end compiler, but the delta is very small and it's<br>
> all<br>
> stuff that we eventually want to do for GL anyway.<br>
><br>
> The main API handling and state setup code is all new and written<br>
> from<br>
> the ground-up for Vulkan. For actually packing hardware packets,<br>
> we are<br>
> using a codegen system that Kristian developed early on in the<br>
> project<br>
> that's based on an XML description of the hardware packets. The<br>
> result<br>
> is state setup code that's both easier to work with and maybe even<br>
> a<br>
> little more efficient than what we have in mesa today.<br>
><br>
> We also have a brand-new surface layout library called ISL that<br>
> handles<br>
> all of the surface layout calculations. ISL should have most of<br>
> the<br>
> code required to do surface layout all the way back to gen4. Once<br>
> we<br>
> get aux surface support in ISL (required for HiZ, MSAA compression,<br>
> and<br>
> CCMS/fast clears), we hope to start using it in the GL driver as<br>
> well.<br>
><br>
> How much code could be shared with other Vulkan drivers?<br>
><br>
> Not as much as you would think. The SPIR-V to NIR translator and<br>
> the<br>
> rest of the NIR compiler stack could obviously be re-used by anyone<br>
> willing to tie NIR into their back-end. The rest of the driver is,<br>
> and<br>
> will probably stay, Intel-specific. Vulkan is a very low-level<br>
> API,<br>
> possibly even lower-level than gallium. A lot of the things that<br>
> we<br>
> share between drivers in mesa today: the front-end compiler, state<br>
> tracking, error-handling, etc. is pushed off to either the<br>
> application<br>
> or third-party layers in the Vulkan world. That said, anyone<br>
> wishing to<br>
> write their own Vulkan driver, is more than welcome to use ours as<br>
> a<br>
> reference and steal whatever they'd like from it.<br>
><br>
> What are your up-streaming plans?<br>
><br>
> Before we can land the SPIR-V to NIR layer, there are a number of<br>
> core<br>
> NIR changes that need to land first. All of that code needs to be<br>
> reviewed as it interacts with the GL driver and we don't want any<br>
> regressions. We are also still carrying a few patches against the<br>
> i965<br>
> back-end compiler that need a little more testing and proper<br>
> review. It<br>
> will take some time to get all of that up-stream.<br>
><br>
> Once that is completed and all of the NIR and i965 back-end bits<br>
> are in<br>
> place, SPIR-V, ISL, and the Vulkan driver itself can probably be<br>
> merged<br>
> without further review since they are fairly self-contained and are<br>
> new<br>
> functionality. We should easily be able to get the driver<br>
> up-stream in<br>
> time for the 11.3 (or 12.0) release.<br>
><br>
> What window-systems are supported?<br>
><br>
> The driver already has window system integration (WSI) support for<br>
> X11<br>
> with DRI3 and Wayland. The Vulkan WSI extensions don't mesh well<br>
> with<br>
> DRI2 so supporting that isn't really an option. If you want to<br>
> Vulkan<br>
> applications under X, you'll need to enable DRI3.<br>
><br>
> Will it run X Vulkan application/demo?<br>
><br>
> Hopefully. Our driver does pass the conformance suite which means<br>
> the<br>
> chances are pretty good that any given app will at least work.<br>
> However,<br>
> no test suite is perfect and our driver and the Vulkan ecosystem<br>
> are<br>
> still young, so there may be bugs. If you do run into problems<br>
> with an<br>
> application, please file a bug against mesa at <a href="http://bugs.freedesktop.org" rel="noreferrer" target="_blank">bugs.freedesktop.org</a><br>
> and<br>
> we will get to it as quickly as we can.<br>
><br>
> Where did Kristian, Jason and Chad go?<br>
><br>
> Well, now you know. :-)<br>
><br>
> We hope you have as much fun hacking on and playing with this driver<br>
> as we<br>
> did writing it. As always, questions, comments, and bug reports are<br>
> more<br>
> than welcome. Happy hacking!<br>
><br>
> Best Regards,<br>
> Jason Ekstrand,<br>
> Kristian Høgsberg Kristensen,<br>
> Chad Versace,<br>
> and the rest of the Intel mesa team<br>
><br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<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>
<br>
</div></div></blockquote></div><br></div></div>