<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 16, 2016 at 1:21 PM, Olivier Galibert <<a href="mailto:galibert@pobox.com" target="_blank">galibert@pobox.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Hi, 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? </blockquote><div> </div><div>It's a depth-stencil issue and we know about it. The gen7 code needs some love. I think Kristian and Jordan have been working on it. </div><div>--Jason </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> OG. <div><div class="h5"> On Tue, Feb 16, 2016 at 4:19 PM, Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> 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 <a href="http://freedesktop.org" rel="noreferrer" target="_blank">freedesktop.org</a>: > > <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> > > More information on building the driver and running a few simple apps can > be found on the <a href="http://01.org" rel="noreferrer" target="_blank">01.org</a> web site: > > <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> > > 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 <a href="http://01.org" rel="noreferrer" target="_blank">01.org</a> > 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 > > <a href="https://cgit.freedesktop.org/mesa/crucible/" rel="noreferrer" target="_blank">https://cgit.freedesktop.org/mesa/crucible/</a> > > 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 <a href="http://bugs.freedesktop.org" rel="noreferrer" target="_blank">bugs.freedesktop.org</a> 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 > > </div></div>> _______________________________________________ > mesa-dev mailing list > <a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a> > <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a> > </blockquote></div> </div></div>