Re: [Mesa-dev] ANNOUNCE: An open-source Vulkan driver for Intel hardware

[Martin Peres]

On 01/03/16 16:33, Olivier Galibert wrote:

I can confirm tri/cube work with latest git.  Talos Principle refuses
to start because of missing vkCmdBeginQuery, time to jump into the
docs to see how much of gen8 is copy-able there.

   OG.


Indeed, I got vkcube to work on HSW. I recompiled everything and this 
time it did not fail.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] ANNOUNCE: An open-source Vulkan driver for Intel hardware

[Jason Ekstrand]

On Mar 1, 2016 1:10 AM, "Martin Peres"  wrote:
>
> On 29/02/16 20:48, Jason Ekstrand wrote:
>>
>> On Fri, Feb 26, 2016 at 2:18 AM, Olivier Galibert 
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
>
>
> Just tried the vkcube with hsw and there is definitely an improvements
(the machine does not hard hang anymore) but vkcube now segfaults:
>
> #0  0x75210f23 in anv_descriptor_set_create () from
/usr/lib/libvulkan_intel.so
> #1  0x7521121d in anv_AllocateDescriptorSets () from
/usr/lib/libvulkan_intel.so
> #2  0x004063b0 in ?? ()
> #3  0x004035df in ?? ()
> #4  0x00404986 in ?? ()
> #5  0x0040589f in ?? ()
> #6  0x76aa9710 in __libc_start_main () from /usr/lib/libc.so.6
> #7  0x00402e69 in ?? ()

For this you need a new version of vkcube.

> Is it supposed to?
>
> I will have a look at it tonight.
>
> Martin
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] ANNOUNCE: An open-source Vulkan driver for Intel hardware

[Olivier Galibert]

I can confirm tri/cube work with latest git.  Talos Principle refuses
to start because of missing vkCmdBeginQuery, time to jump into the
docs to see how much of gen8 is copy-able there.

  OG.


On Tue, Mar 1, 2016 at 10:28 AM, Jacek Konieczny  wrote:
> On 2016-03-01 10:10, Martin Peres wrote:
>>
>> On 29/02/16 20:48, Jason Ekstrand wrote:
>>>
>>> On Fri, Feb 26, 2016 at 2:18 AM, Olivier Galibert >> > 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
>>
>>
>> Just tried the vkcube with hsw and there is definitely an improvements
>> (the machine does not hard hang anymore) but vkcube now segfaults:
>
>
> For me both 'vkcube' and the 'cube' and 'tri' demos from
> LoaderAndValidationLayers work correctly with GIT revision
> 46b7c242da7c7c9ea7877a2c4b1fecdf5c1c0452.
>
> 'cube', 'tri' and most other Vulkan examples would cause GPU hang on
> earlier revisions, so the improvement is (was?) clear.
>
> Jacek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] ANNOUNCE: An open-source Vulkan driver for Intel hardware

[Olivier Galibert]

Beware of path issues, vk* has no error checking and gives funky
values to the driver if it fails at finding its extra files.

  OG.


On Tue, Mar 1, 2016 at 10:10 AM, Martin Peres  wrote:
> On 29/02/16 20:48, Jason Ekstrand wrote:
>
> On Fri, Feb 26, 2016 at 2:18 AM, Olivier Galibert 
> 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
>
>
> Just tried the vkcube with hsw and there is definitely an improvements (the
> machine does not hard hang anymore) but vkcube now segfaults:
>
> #0  0x75210f23 in anv_descriptor_set_create () from
> /usr/lib/libvulkan_intel.so
> #1  0x7521121d in anv_AllocateDescriptorSets () from
> /usr/lib/libvulkan_intel.so
> #2  0x004063b0 in ?? ()
> #3  0x004035df in ?? ()
> #4  0x00404986 in ?? ()
> #5  0x0040589f in ?? ()
> #6  0x76aa9710 in __libc_start_main () from /usr/lib/libc.so.6
> #7  0x00402e69 in ?? ()
>
> Is it supposed to?
>
> I will have a look at it tonight.
>
> Martin
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] ANNOUNCE: An open-source Vulkan driver for Intel hardware

[Martin Peres]

On 01/03/16 13:21, Kenneth Graunke wrote:

On Tuesday, March 1, 2016 11:10:25 AM PST Martin Peres wrote:

On 29/02/16 20:48, Jason Ekstrand wrote:

On Fri, Feb 26, 2016 at 2:18 AM, Olivier Galibert mailto: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


Just tried the vkcube with hsw and there is definitely an improvements
(the machine does not hard hang anymore) but vkcube now segfaults:

#0  0x75210f23 in anv_descriptor_set_create () from
/usr/lib/libvulkan_intel.so
#1  0x7521121d in anv_AllocateDescriptorSets () from
/usr/lib/libvulkan_intel.so
#2  0x004063b0 in ?? ()
#3  0x004035df in ?? ()
#4  0x00404986 in ?? ()
#5  0x0040589f in ?? ()
#6  0x76aa9710 in __libc_start_main () from /usr/lib/libc.so.6
#7  0x00402e69 in ?? ()

Is it supposed to?

I will have a look at it tonight.

Martin



Taking a stab in the dark here...

Do you have CONFIG_MMU_NOTIFIER enabled in your kernel?  You need that
for userptr to work, which is used for allocating everything (including
descriptor sets).


$ zcat /proc/config.gz | grep CONFIG_MMU_NOTIFIER
CONFIG_MMU_NOTIFIER=y



Otherwise, you might try clean builds.  Also, make sure you're running
vkcube from here: https://github.com/krh/vkcube


I updated the version and it seems to be working enough to get the 
kernel to complain now:


[10262.029000] vkcube[32526]: segfault at 1 ip 004069da sp 
7ffc384c8dc0 error 6 in vkcube[40+a000]
[10262.029021] audit: type=1701 audit(1456831951.457:765): auid=1000 
uid=1000 gid=1000 ses=4 pid=32526 comm="vkcube" exe="/usr/bin/vkcube" sig=11

[10270.639768] [ cut here ]
[10270.639809] WARNING: CPU: 7 PID: 505 at 
drivers/gpu/drm/i915/intel_display.c:13774 
intel_prepare_plane_fb+0x268/0x2d0 [i915]()

[10270.639811] WARN_ON(ret < 0)
[10270.639812] Modules linked in:
[10270.639813]  fuse snd_hda_codec_hdmi x86_pkg_temp_thermal coretemp 
kvm_intel kvm irqbypass crc32c_intel i915 aesni_intel snd_emu10k1 
aes_x86_64 snd_hda_codec_realtek ablk_helper snd_util_mem iTCO_wdt 
efi_pstore ppdev mxm_wmi snd_hda_codec_generic cryptd 
iTCO_vendor_support lrw snd_ac97_codec drm_kms_helper gf128mul 
snd_hda_intel glue_helper ac97_bus snd_hda_codec drm snd_rawmidi psmouse 
snd_hda_core snd_seq_device snd_hwdep efivars intel_gtt serio_raw pcspkr 
syscopyarea snd_pcm i2c_i801 sysfillrect sysimgblt snd_timer fb_sys_fops 
i2c_algo_bit emu10k1_gp snd gameport r8169 soundcore lpc_ich mii thermal 
fan battery parport_pc parport tpm_infineon wmi tpm_tis tpm video 
acpi_pad processor button evdev joydev sch_fq_codel ip_tables x_tables 
ext4 crc16 mbcache jbd2 hid_generic usbhid hid sd_mod ahci libahci
[10270.639852]  libata scsi_mod firewire_ohci firewire_core crc_itu_t 
xhci_pci ehci_pci xhci_hcd ehci_hcd usbcore usb_common
[10270.639859] CPU: 7 PID: 505 Comm: Xorg Tainted: GW 
4.4.0-rc6-NV+ #18
[10270.639860] Hardware name: MSI MS-7850/Z97 PC Mate(MS-7850), BIOS 
V4.7 12/23/2014
[10270.639861]  a0d37e20 88040b2379b0 812a8629 
88040b2379f8
[10270.639863]  88040b2379e8 8105bf22 8800d8b3c480 
8800d8b3c480
[10270.639864]  880403a0e6c0 88040b9a3400 8800a524fd80 
88040b237a48

[10270.639866] Call Trace:
[10270.639874]  [] dump_stack+0x4b/0x72
[10270.639878]  [] warn_slowpath_common+0x82/0xc0
[10270.639879]  [] warn_slowpath_fmt+0x4c/0x50
[10270.639893]  [] intel_prepare_plane_fb+0x268/0x2d0 
[i915]
[10270.639901]  [] 
drm_atomic_helper_prepare_planes+0x53/0xc0 [drm_kms_helper]

[10270.639913]  [] intel_atomic_commit+0x247/0x17d0 [i915]
[10270.639927]  [] ? drm_atomic_check_only+0x196/0x5b0 
[drm]
[10270.639936]  [] ? 
drm_atomic_get_crtc_state+0x32/0xd0 [drm]

[10270.639943]  [] drm_atomic_commit+0x37/0x60 [drm]
[10270.639947]  [] 
drm_atomic_helper_update_plane+0xec/0x130 [drm_kms_helper]

[10270.639954]  [] __setplane_internal+0x202/0x250 [drm]
[10270.639960]  [] 
drm_mode_cursor_universal+0x124/0x200 [drm]

[10270.639966]  [] drm_mode_cursor_common+0x81/0x180 [drm]
[10270.639968]  [] ? sock_sendmsg+0x38/0x50
[10270.639975]  [] drm_mode_cursor_ioctl+0x41/0x50 [drm]
[10270.639980]  [] drm_ioctl+0x152/0x540 [drm]
[10270.639986]  [] ? drm_mode_setcrtc+0x4e0/0x4e0 [drm]
[10270.639989]  [] ? __audit_syscall_exit+0x1dd/0x260
[10270.639991]  [] do_vfs_ioctl+0x288/0x470
[10270.639993]  [] ? __fget+0x77/0xb0
[10270.639995]  [] SyS_ioctl+0x79/0x90
[10270.639997]  [] entry_SYSCALL_64_fastpath+0x16/0x6e
[10270.639998] ---[ end trace 52de0a0f139c19d3 ]---
[10270.644120] [ cut here ]
[10270.644149] WARNING: CPU: 6 PID: 505 at 
drivers/gpu/drm/i915/intel_display.c:13774 
intel_prepar

Re: [Mesa-dev] ANNOUNCE: An open-source Vulkan driver for Intel hardware

[Kenneth Graunke]

On Tuesday, March 1, 2016 11:10:25 AM PST Martin Peres wrote:
> On 29/02/16 20:48, Jason Ekstrand wrote:
> > On Fri, Feb 26, 2016 at 2:18 AM, Olivier Galibert  > > 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
> 
> Just tried the vkcube with hsw and there is definitely an improvements 
> (the machine does not hard hang anymore) but vkcube now segfaults:
> 
> #0  0x75210f23 in anv_descriptor_set_create () from 
> /usr/lib/libvulkan_intel.so
> #1  0x7521121d in anv_AllocateDescriptorSets () from 
> /usr/lib/libvulkan_intel.so
> #2  0x004063b0 in ?? ()
> #3  0x004035df in ?? ()
> #4  0x00404986 in ?? ()
> #5  0x0040589f in ?? ()
> #6  0x76aa9710 in __libc_start_main () from /usr/lib/libc.so.6
> #7  0x00402e69 in ?? ()
> 
> Is it supposed to?
> 
> I will have a look at it tonight.
> 
> Martin
> 

Taking a stab in the dark here...

Do you have CONFIG_MMU_NOTIFIER enabled in your kernel?  You need that
for userptr to work, which is used for allocating everything (including
descriptor sets).

Otherwise, you might try clean builds.  Also, make sure you're running
vkcube from here: https://github.com/krh/vkcube


signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] ANNOUNCE: An open-source Vulkan driver for Intel hardware

[Jacek Konieczny]

On 2016-03-01 10:10, Martin Peres wrote:

On 29/02/16 20:48, Jason Ekstrand wrote:

On Fri, Feb 26, 2016 at 2:18 AM, Olivier Galibert mailto: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


Just tried the vkcube with hsw and there is definitely an improvements
(the machine does not hard hang anymore) but vkcube now segfaults:


For me both 'vkcube' and the 'cube' and 'tri' demos from
LoaderAndValidationLayers work correctly with GIT revision
46b7c242da7c7c9ea7877a2c4b1fecdf5c1c0452.

'cube', 'tri' and most other Vulkan examples would cause GPU hang on
earlier revisions, so the improvement is (was?) clear.

Jacek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] ANNOUNCE: An open-source Vulkan driver for Intel hardware

[Martin Peres]

On 29/02/16 20:48, Jason Ekstrand wrote:
On Fri, Feb 26, 2016 at 2:18 AM, Olivier Galibert > 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


Just tried the vkcube with hsw and there is definitely an improvements 
(the machine does not hard hang anymore) but vkcube now segfaults:


#0  0x75210f23 in anv_descriptor_set_create () from 
/usr/lib/libvulkan_intel.so
#1  0x7521121d in anv_AllocateDescriptorSets () from 
/usr/lib/libvulkan_intel.so

#2  0x004063b0 in ?? ()
#3  0x004035df in ?? ()
#4  0x00404986 in ?? ()
#5  0x0040589f in ?? ()
#6  0x76aa9710 in __libc_start_main () from /usr/lib/libc.so.6
#7  0x00402e69 in ?? ()

Is it supposed to?

I will have a look at it tonight.

Martin
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] ANNOUNCE: An open-source Vulkan driver for Intel hardware

[Jason Ekstrand]

On Fri, Feb 26, 2016 at 2:18 AM, Olivier Galibert 
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 
> wrote:
> > On Tue, Feb 16, 2016 at 11:22 PM, Olivier Galibert 
> > 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 
> >> wrote:
> >> > On Tue, Feb 16, 2016 at 1:21 PM, Olivier Galibert  >
> >> > 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.
> >> >> >
> >>

Re: [Mesa-dev] ANNOUNCE: An open-source Vulkan driver for Intel hardware

[Olivier Galibert]

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  wrote:
> On Tue, Feb 16, 2016 at 11:22 PM, Olivier Galibert 
> 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 
>> wrote:
>> > On Tue, Feb 16, 2016 at 1:21 PM, Olivier Galibert 
>> > 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 
>> >> 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 

Re: [Mesa-dev] ANNOUNCE: An open-source Vulkan driver for Intel hardware

[Olivier Galibert]

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  wrote:
> On Tue, Feb 16, 2016 at 11:22 PM, Olivier Galibert 
> 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 
>> wrote:
>> > On Tue, Feb 16, 2016 at 1:21 PM, Olivier Galibert 
>> > 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 
>> >> 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.
>> >> >
>> >> >

Re: [Mesa-dev] ANNOUNCE: An open-source Vulkan driver for Intel hardware

[Thomas Helland]

17. feb. 2016 16.37 skrev "Jason Ekstrand" :
>
> On Tue, Feb 16, 2016 at 11:41 PM, Iago Toral  wrote:
>>
>> Hey Jason,
>>
>> this is awesome news, congrats to all the people involved!
>
>
> Thanks!
>
>>
>> Did you have a chance to try the new driver with anything other than
>> conformance tests or small demos? I know it is still in a very early
>> stage but I'd like to know your impressions about how much of an
>> improvement it brings over the GL driver in its current form and whether
>> there is still major optimization work to be done. I figure that since
>> you are using NIR and the same compiler backend used for GL things
>> should be looking pretty good already.
>
>
> We have had early access to a few apps.  I've almost got dota2 working
(still fighting a rendering corruption), but the driver seems to be working
pretty well.  I think we're doing pretty good on the stability front, but
driver isn't quite up to the same performance standards as the GL driver.
Not a problem with Vulkan, more that this is a new driver and we haven't
had time to do everything yet.
>
> What's left to be done?  Well, there are some hardware optimizations we
haven't turned on yet such as HiZ.  There are also a few compiler things
that need to be done.  The one big gaping hole is that NIR doesn't have
loop unrolling yet.  Thomas Helland was working on that over the summer but
his time was divided between loop unrolling and range analysis and so it
never got finished.

This is fabulous! Congrats on the work well done!
I was working on rebasing the loop unrolling code a couple weeks ago.
I don't quite remember how far I got though. I'll push a rebased version
once I get back from Hong Kong, one of the coming days.

I wrote a LCSSA conversion pass and a loop analysis pass that worked
decently, and gave no piglit regressions. I did not get to the loop
unrolling part though. Someone else should probably look into that.
(After having a 3-week Australia-roadtrip in the midst of my master
thesis I have some catching up to do).

For the code as it was at the end of GSoC, look at [1].
If there's any questions be sure to let me know, and I'll try to
answer to the best of my knowledge.

--Thomas

[1] https://github.com/thohel/mesa
> --Jason
>
>>
>>
>> Iago
>>
>> On Tue, 2016-02-16 at 07:19 -0800, Jason Ekstrand 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
>> > 

Re: [Mesa-dev] ANNOUNCE: An open-source Vulkan driver for Intel hardware

[Jason Ekstrand]

On Tue, Feb 16, 2016 at 11:41 PM, Iago Toral  wrote:

> Hey Jason,
>
> this is awesome news, congrats to all the people involved!
>

Thanks!


> Did you have a chance to try the new driver with anything other than
> conformance tests or small demos? I know it is still in a very early
> stage but I'd like to know your impressions about how much of an
> improvement it brings over the GL driver in its current form and whether
> there is still major optimization work to be done. I figure that since
> you are using NIR and the same compiler backend used for GL things
> should be looking pretty good already.
>

We have had early access to a few apps.  I've almost got dota2 working
(still fighting a rendering corruption), but the driver seems to be working
pretty well.  I think we're doing pretty good on the stability front, but
driver isn't quite up to the same performance standards as the GL driver.
Not a problem with Vulkan, more that this is a new driver and we haven't
had time to do everything yet.

What's left to be done?  Well, there are some hardware optimizations we
haven't turned on yet such as HiZ.  There are also a few compiler things
that need to be done.  The one big gaping hole is that NIR doesn't have
loop unrolling yet.  Thomas Helland was working on that over the summer but
his time was divided between loop unrolling and range analysis and so it
never got finished.
--Jason


>
> Iago
>
> On Tue, 2016-02-16 at 07:19 -0800, Jason Ekstrand 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

Re: [Mesa-dev] ANNOUNCE: An open-source Vulkan driver for Intel hardware

[Jason Ekstrand]

On Tue, Feb 16, 2016 at 11:22 PM, Olivier Galibert 
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 
> wrote:
> > On Tue, Feb 16, 2016 at 1:21 PM, Olivier Galibert 
> > 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 
> >> 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
> >> >  

Re: [Mesa-dev] ANNOUNCE: An open-source Vulkan driver for Intel hardware

[Iago Toral]

Hey Jason,

this is awesome news, congrats to all the people involved!

Did you have a chance to try the new driver with anything other than
conformance tests or small demos? I know it is still in a very early
stage but I'd like to know your impressions about how much of an
improvement it brings over the GL driver in its current form and whether
there is still major optimization work to be done. I figure that since
you are using NIR and the same compiler backend used for GL things
should be looking pretty good already.

Iago

On Tue, 2016-02-16 at 07:19 -0800, Jason Ekstrand 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 t

Re: [Mesa-dev] ANNOUNCE: An open-source Vulkan driver for Intel hardware

[Olivier Galibert]

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.

Best,

  OG.


On Wed, Feb 17, 2016 at 2:51 AM, Jason Ekstrand  wrote:
> On Tue, Feb 16, 2016 at 1:21 PM, Olivier Galibert 
> 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 
>> 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-handlin

Re: [Mesa-dev] ANNOUNCE: An open-source Vulkan driver for Intel hardware

[Jason Ekstrand]

On Tue, Feb 16, 2016 at 1:21 PM, Olivier Galibert 
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 
> 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 w

Re: [Mesa-dev] ANNOUNCE: An open-source Vulkan driver for Intel hardware

[Connor Abbott]

The first thing I would do is to try running it under valgrind and see
if there are any errors. Make sure to have the valgrind development
headers installed when building mesa, as anvil has a lot of special
valgrind hooks builtin that it will only use if it finds the header
during the build.

On Tue, Feb 16, 2016 at 4:21 PM, Olivier Galibert  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?
>
>   OG.
>
>
> On Tue, Feb 16, 2016 at 4:19 PM, Jason Ekstrand  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 

[Mesa-dev] ANNOUNCE: An open-source Vulkan driver for Intel hardware

[Jason Ekstrand]

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 wa