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

Olivier Galibert galibert at pobox.com
Tue Feb 16 21:21:20 UTC 2016


I'm getting gpu hangs with the lunarg examples (cube and tri) on my
Haswell (64 bits).  I attach /sys/class/drm/card0/error fwiw.  How
should I go about debugging that?


On Tue, Feb 16, 2016 at 4:19 PM, Jason Ekstrand <jason at jlekstrand.net> wrote:
> 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
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: err.txt.bz2
Type: application/x-bzip2
Size: 303352 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160216/c10da618/attachment-0001.bin>

More information about the mesa-dev mailing list