Ok, I'll do that, thanks :-) No matter what, I'll learn interesting things.
OG. On Wed, Feb 17, 2016 at 4:31 PM, Jason Ekstrand <ja...@jlekstrand.net> wrote: > On Tue, Feb 16, 2016 at 11:22 PM, Olivier Galibert <galib...@pobox.com> > wrote: >> >> I'm actually interested about how one goes about debugging that kind >> of problem, if you have pointers. I would have an idea or two on how >> to go about it if it was in userspace only, but once it crosses into >> the kernel I'm not sure what strategies are best. > > > This is almost certainly a userspace problem. I mentioned before that it's > probably a depth/stencil problem. I remember having similar problems a few > months ago when I was reviving gen7. I know that depth/stencil did work at > some point. > > I would start by looking at is where we emit the 3DSTATE_DEPTH_BUFFER and > 3DSTATE_STENCIL_BUFFER and trying to see if we're setting something up > wrong. Sometimes it's just a matter of looking at the documentation and > comparing the values we're setting to the docs and seeing if the make sense. > That's where I'd start. > > You could also try to go back a little ways (don't to past the update to > 1.0) to see if you can find a point where depth/stencil worked and try and > bisect to find where it broke. That may also provide hints as to what's > going wrong. > > Hope that helps, > --Jason > >> >> >> Best, >> >> OG. >> >> >> On Wed, Feb 17, 2016 at 2:51 AM, Jason Ekstrand <ja...@jlekstrand.net> >> wrote: >> > On Tue, Feb 16, 2016 at 1:21 PM, Olivier Galibert <galib...@pobox.com> >> > wrote: >> >> >> >> 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? >> > >> > >> > 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. >> > --Jason >> > >> >> >> >> >> >> OG. >> >> >> >> >> >> On Tue, Feb 16, 2016 at 4:19 PM, Jason Ekstrand <ja...@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@lists.freedesktop.org >> >> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev >> >> > >> > >> > > > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
