[Mesa-announce] ANNOUNCE: An open-source Vulkan driver for Intel hardware

[Jason Ekstrand]

The Intel mesa team is pleased to announce a brand-new open-source Vulkan
driver for Intel hardware.  We've been working hard on this over the course
of the past year or so and are excited to finally share it with the
community.  We will work on up-streaming the driver in the next few weeks
and hope to have it all in place in time for mesa 11.3 (mesa 12?).  In the
mean time, the driver can be found in the "vulkan" branch of the mesa git
repo on freedesktop.org:

https://cgit.freedesktop.org/mesa/mesa/log/?h=vulkan

More information on building the driver and running a few simple apps can
be found on the 01.org web site:

https://01.org/linuxgraphics/blogs/jekstrand/2016/open-source-vulkan-drivers-intel-hardware

We have talked to people at Red Hat and Cannonical and binaries should be
available for Fedora and Ubuntu soon.  We will update the page on 01.org
with links as soon as they are available.

We have also created a small test suite called crucible which contains a
few hundred tests (mostly for miptrees) that we created when bringing up
the driver.  This isn't really intended to be the piglit of vulkan.  With
the CTS being publicly available, most cross-platform tests should go
there.  We mostly made crucible so that we could write a few tests early on
to get us going and for tests that were targetted specifically at our
implementation.  None the less, they may prove useful to someone and we are
happy to share them.  The crucible source code can be found at

https://cgit.freedesktop.org/mesa/crucible/

Frequently Asked Questions:

What all hardware does it support?

   The driver currently supports Sky Lake all the way back to Ivy Bridge.
   The driver is Vulkan 1.0 conformant for 64-bit builds on Sky Lake,
   Broadwell, and Braswell.  We are still having a couple of 32-bit issues
   and support for Haswell, Ivy Bridge, and Bay Trail should be considered
   experimental.

How much code is shared between the Vulkan and GL drivers?

   For shaders, we're using a SPIR-V to NIR pass which is new, and a few
   new NIR lowering passes for things that we previously depended on GLSL
   IR to handle.  Beyond that, we're using the same core NIR and the same
   back-end compiler that we have for GL.  We're carrying a few patches
   against the back-end compiler, but the delta is very small and it's all
   stuff that we eventually want to do for GL anyway.

   The main API handling and state setup code is all new and written from
   the ground-up for Vulkan.  For actually packing hardware packets, we are
   using a codegen system that Kristian developed early on in the project
   that's based on an XML description of the hardware packets.  The result
   is state setup code that's both easier to work with and maybe even a
   little more efficient than what we have in mesa today.

   We also have a brand-new surface layout library called ISL that handles
   all of the surface layout calculations.  ISL should have most of the
   code required to do surface layout all the way back to gen4.  Once we
   get aux surface support in ISL (required for HiZ, MSAA compression, and
   CCMS/fast clears), we hope to start using it in the GL driver as well.

How much code could be shared with other Vulkan drivers?

   Not as much as you would think.  The SPIR-V to NIR translator and the
   rest of the NIR compiler stack could obviously be re-used by anyone
   willing to tie NIR into their back-end.  The rest of the driver is, and
   will probably stay, Intel-specific.  Vulkan is a very low-level API,
   possibly even lower-level than gallium.  A lot of the things that we
   share between drivers in mesa today: the front-end compiler, state
   tracking, error-handling, etc. is pushed off to either the application
   or third-party layers in the Vulkan world.  That said, anyone wishing to
   write their own Vulkan driver, is more than welcome to use ours as a
   reference and steal whatever they'd like from it.

What are your up-streaming plans?

   Before we can land the SPIR-V to NIR layer, there are a number of core
   NIR changes that need to land first.  All of that code needs to be
   reviewed as it interacts with the GL driver and we don't want any
   regressions.  We are also still carrying a few patches against the i965
   back-end compiler that need a little more testing and proper review.  It
   will take some time to get all of that up-stream.

   Once that is completed and all of the NIR and i965 back-end bits are in
   place, SPIR-V, ISL, and the Vulkan driver itself can probably be merged
   without further review since they are fairly self-contained and are new
   functionality.  We should easily be able to get the driver up-stream in
   time for the 11.3 (or 12.0) release.

What window-systems are supported?

   The driver already has window system integration (WSI) support for X11
   with DRI3 and Wayland.  The Vulkan WSI extensions don't mesh well with
   DRI2 so supporting that isn't really an option.  If you want to Vulkan
   applications under X, you'll need to enable DRI3.

Will it run X Vulkan application/demo?

   Hopefully.  Our driver does pass the conformance suite which means the
   chances are pretty good that any given app will at least work.  However,
   no test suite is perfect and our driver and the Vulkan ecosystem are
   still young, so there may be bugs.  If you do run into problems with an
   application, please file a bug against mesa at bugs.freedesktop.org and
   we will get to it as quickly as we can.

Where did Kristian, Jason and Chad go?

   Well, now you know. :-)

We hope you have as much fun hacking on and playing with this driver as we
did writing it.  As always, questions, comments, and bug reports are more
than welcome.  Happy hacking!

Best Regards,
Jason Ekstrand,
Kristian Høgsberg Kristensen,
Chad Versace,
and the rest of the Intel mesa team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-announce/attachments/20160216/269c4bb4/attachment.html>