On Fri, Feb 26, 2016 at 2:18 AM, Olivier Galibert <galib...@pobox.com> wrote:
> Ok, I can tell you that 3DSTATE_DEPTH_BUFFER and > 3DSTATE_STENCIL_BUFFER seem perfectly correct (assuming the gem > address-patching-in works for the depth buffer address). I'll see if > I can find a past version that works. > FYI, this hang has been fixed now and most of the demos work more-or-less. --Jason > > 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
