[Mesa-dev] ANNOUNCE: An open-source Vulkan driver for Intel hardware
Jason Ekstrand
jason at jlekstrand.net
Mon Feb 29 18:48:05 UTC 2016
On Fri, Feb 26, 2016 at 2:18 AM, Olivier Galibert <galibert at 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 <jason at jlekstrand.net>
> wrote:
> > On Tue, Feb 16, 2016 at 11:22 PM, Olivier Galibert <galibert at 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 <jason at jlekstrand.net>
> >> wrote:
> >> > On Tue, Feb 16, 2016 at 1:21 PM, Olivier Galibert <galibert at 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 <
> 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 --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160229/4649e33b/attachment-0001.html>
More information about the mesa-dev
mailing list