[Mesa-dev] ANNOUNCE: An open-source Vulkan driver for Intel hardware
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:
> More information on building the driver and running a few simple apps can
> be found on the 01.org web site:
> 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
> 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
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 303352 bytes
Desc: not available
More information about the mesa-dev