[Mesa-dev] ANNOUNCE: An open-source Vulkan driver for Intel hardware
Olivier Galibert
galibert at pobox.com
Fri Feb 26 10:18:09 UTC 2016
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.
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
>> >> >
>> >
>> >
>
>
More information about the mesa-dev
mailing list