Switch to DuckDuckGo Search
   May 24, 2018
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31

bottom
[00:00:11] <dyl> I can get glfw to log more verbosely somehow can't I?
[00:01:24] <dyl> I should set an error callback for GLFW to get more info.
[00:02:50] <dyl> ...no errors logged .__.
[00:03:23] <dyl> There's a _glfwInputError on every possible fail path.
[00:03:25] <dyl> What is this.
[00:07:35] <dyl> It's definitely _glfwInitVulkan failing, I know that much.
[00:07:53] <dyl> https://github.com/glfw/glfw/blob/3.2.1/src/vulkan.c#L57
[00:08:09] <dyl> This appears to be the failure site as it's the only one I wouldn't get any additional error prints from.
[00:08:24] <dyl> So, yeah, it's not finding the dynamic library for some reason.
[00:09:32] *** ryp <ryp!~ryp@14.244.29.109.rev.sfr.net> has quit IRC (Ping timeout: 252 seconds)
[00:11:18] <dyl> AYFKM
[00:11:26] <dyl> It's looking for libvulkan.so.1.
[00:11:32] <dyl> And not libvulkan.1.dylib, it seems.
[00:11:50] *** Guest43402 <Guest43402!~james@static-96-43-65-242.albyny.csvoip.net> has quit IRC (Quit: Leaving)
[00:12:27] <dyl> I have glfw 3.2.1, in that tag as shown above, it doesn't look for a dylib properly.
[00:12:44] <dyl> ...master however does.
[00:13:09] <dyl> Let's try with --HEAD...
[00:13:18] <dyl> How did this even work before..?
[00:14:00] *** davr0s <davr0s!~textual@host86-149-134-190.range86-149.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[00:15:16] <dyl> and it works!
[00:15:19] <dyl> mefesto .___.
[00:15:35] <dyl> It was this commit, which is still not in stable.
[00:15:35] <dyl> https://github.com/glfw/glfw/commit/ab3bfb420544bad92145c626b351b7f279425aea
[00:16:53] <dyl> The weird notch in the corner problem is gone too.
[00:18:15] <dyl> Thanks for your help/rubberducking mefesto.
[00:18:20] <dyl> In the end it was just a bug :/.
[00:20:05] *** borkr <borkr!~borkr@static130-244.mimer.net> has quit IRC (Ping timeout: 240 seconds)
[00:30:12] <cinch> this works for me: target_link_libraries(${PROJECT_NAME} vulkan glfw)
[00:31:13] <dyl> It wasn't a compile time issue.
[00:31:25] <dyl> It was that the latest stable version of glfw simply *doesn't look for the right thing*.
[00:31:41] <dyl> Mach-O dynamic libraries are named <name>.<version>.dylib
[00:31:47] <dyl> Not <name>.so.<version>
[00:32:01] <dyl> Installing HEAD fixed it right up.
[00:34:33] * M-penguin42 has a couple of newbie questions and I'm not 100% sure whether they're actually vulkan or the Rust language wrapper I'm using (vulkano); but here goes
[00:35:32] <M-penguin42> I'm converting from OpenCL; and have a couple of kernels; I've got a 3d structure that needs to get passed from the 1st kernel to the 2nd; in Vulkan is that still a 3d image?
[00:36:59] <M-penguin42> but then Vulkano has many types of image/image flags - what type do I need for something that's never displayed - purely holding compute data between two kernels?
[00:44:04] <dyl> I think you would just use a buffer of some kind.
[00:45:02] <dyl> There’s still 3D images though so I don’t know.
[00:50:21] <M-penguin42> dyl: Any reason you suggest using a buffer then?  Doesn't using the image mean that I get all the x/y/z index calculation done for me?
[00:58:08] *** derhass <derhass!~derhass@ipservice-092-217-211-202.092.217.pools.vodafone-ip.de> has quit IRC (Quit: leaving)
[01:06:10] *** ryp <ryp!~ryp@14.244.29.109.rev.sfr.net> has joined ##vulkan
[01:22:14] <dyl> Buffer is just the most generic thing. I wouldn’t be the one to ask though, someone else here can likely tell you exactly.
[01:25:15] *** ryp <ryp!~ryp@14.244.29.109.rev.sfr.net> has quit IRC (Ping timeout: 245 seconds)
[01:25:56] <M-penguin42> nod, thanks anyway
[01:26:15] <M-penguin42> Compute examples seem to be a bit rarer
[01:52:35] *** glYoda <glYoda!~MTLYoda@c-73-25-27-206.hsd1.or.comcast.net> has quit IRC (Quit: glYoda)
[02:00:04] *** slime <slime!~slime73@blk-215-81-93.eastlink.ca> has joined ##vulkan
[02:10:04] *** mandeep <mandeep!mandeep@gateway/vpn/privateinternetaccess/mandeepb> has joined ##vulkan
[02:14:28] *** halbeno <halbeno!~halbeno@node-1w7jra22dpc6yveqvcvcv9ype.ipv6.telus.net> has quit IRC (Quit: Leaving)
[02:16:41] *** halbeno <halbeno!~halbeno@node-1w7jra22dpc6yrvo9wam83mu0.ipv6.telus.net> has joined ##vulkan
[02:19:40] <mefesto> dyl: glad you got it going. why are you using bleeding edge glfw?
[02:19:49] *** cheakoirccloud <cheakoirccloud!uid293319@gateway/web/irccloud.com/x-yccaqrbahishfzym> has joined ##vulkan
[02:20:08] <ratchetfreak> I guess for the moltenvk compat
[02:21:01] <dyl> mefesto: because the latest stable version doesn’t support MacOS Vulkan
[02:21:08] <dyl> This was apparently just fixed in March.
[02:21:18] <mefesto> ah
[02:21:18] <dyl> And there hasn’t been a stable GLFW release in a bit.
[02:22:17] <dyl> Looks like MoltenVK just became open source earlier this year also.
[02:22:21] <dyl> So that’s not too surprising.
[02:22:29] <dyl> But still I’d expect a minor revision at least.
[02:22:37] <dyl> (From GLFW.)
[02:23:37] <dyl> The homepage has them at 94% to 3.3 though.
[02:23:44] <dyl> So they’re probably holding out for that.
[02:24:12] <dyl> “The current version is 3.2.1, which was released on August 18, 2016.”
[02:24:15] <dyl> That explains it haha
[02:25:49] *** glYoda <glYoda!~MTLYoda@c-73-25-27-206.hsd1.or.comcast.net> has joined ##vulkan
[02:30:49] *** slime <slime!~slime73@blk-215-81-93.eastlink.ca> has quit IRC (Quit: This computer has gone to sleep)
[02:31:55] <dyl> glYoda is MTLYoda?
[02:32:00] <dyl> Soon... DirectYoda?
[02:32:16] <dyl> VkYoda?
[02:33:07] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-82s3g7l5qi77ye7huk9.18120a2.ip6.access.telenet.be> has quit IRC (Ping timeout: 245 seconds)
[03:03:59] *** slime <slime!~slime73@24.215.81.93> has joined ##vulkan
[03:07:36] *** hlmjr <hlmjr!~herb@c-76-120-173-141.hsd1.pa.comcast.net> has joined ##vulkan
[03:33:45] *** slime <slime!~slime73@24.215.81.93> has quit IRC (Quit: This computer has gone to sleep)
[03:46:30] *** jdashg <jdashg!~jdashg@corp-nat.fw1.untrust.mtv2.mozilla.net> has quit IRC (Ping timeout: 245 seconds)
[03:53:04] *** slime <slime!~slime73@24.215.81.93> has joined ##vulkan
[04:36:17] *** slime <slime!~slime73@24.215.81.93> has quit IRC (Quit: This computer has gone to sleep)
[05:51:56] *** halbeno <halbeno!~halbeno@node-1w7jra22dpc6yrvo9wam83mu0.ipv6.telus.net> has quit IRC (Remote host closed the connection)
[05:52:21] *** halbeno <halbeno!~halbeno@node-1w7jra22dpc6yrvo9wam83mu0.ipv6.telus.net> has joined ##vulkan
[06:20:25] *** Keith_ <Keith_!~Keith@2606:6000:4380:4800:41f8:c4e8:6838:b0cc> has joined ##vulkan
[06:21:00] *** Keith_ is now known as wandering-human
[06:29:27] *** wandering-human <wandering-human!~Keith@2606:6000:4380:4800:41f8:c4e8:6838:b0cc> has left ##vulkan ("Leaving")
[06:32:42] *** Salek <Salek!~salek@91-155-9-229.elisa-laajakaista.fi> has quit IRC (Ping timeout: 245 seconds)
[06:33:38] *** cocholate_ <cocholate_!~cppfag@187.67.9.46> has joined ##vulkan
[06:34:35] *** cocholate <cocholate!~cppfag@187.67.9.46> has quit IRC (Ping timeout: 240 seconds)
[06:37:50] *** mefesto <mefesto!~user@107.145.49.162> has quit IRC (Ping timeout: 252 seconds)
[06:37:58] *** cheakoirccloud <cheakoirccloud!uid293319@gateway/web/irccloud.com/x-yccaqrbahishfzym> has quit IRC (Quit: Connection closed for inactivity)
[07:27:48] *** nsf <nsf!~nsf@jiss.convex.ru> has joined ##vulkan
[07:37:38] *** daxar4 <daxar4!~daxar@193-154-247-125.adsl.highway.telekom.at> has joined ##vulkan
[07:40:40] *** daxar3 <daxar3!~daxar@193-154-247-2.adsl.highway.telekom.at> has quit IRC (Ping timeout: 245 seconds)
[07:51:36] *** grouse <grouse!~grouse@83-233-9-2.cust.bredband2.com> has joined ##vulkan
[07:53:02] *** Kingsquee <Kingsquee!~kingsquee@d162-156-55-229.bchsia.telus.net> has joined ##vulkan
[07:53:03] *** Yolarina <Yolarina!~Polarina@wesnoth/translator/Polarina> has joined ##vulkan
[07:54:00] *** Polarina <Polarina!~Polarina@wesnoth/translator/Polarina> has quit IRC (Read error: Connection reset by peer)
[07:59:34] *** ryp <ryp!~ryp@14.244.29.109.rev.sfr.net> has joined ##vulkan
[08:15:18] *** davr0s <davr0s!~textual@host86-149-134-190.range86-149.btcentralplus.com> has joined ##vulkan
[08:19:21] *** Salek <Salek!~salek@91-155-9-229.elisa-laajakaista.fi> has joined ##vulkan
[08:20:37] *** it_ <it_!b2c5eb1b@gateway/web/freenode/ip.178.197.235.27> has joined ##vulkan
[08:22:39] <it_> Hello. For school I have a task where I need to render a couple of different objects each with different shaders, "worst-case". They can all be the same but should have their own vertex buffers
[08:23:20] <it_> Am I understanding this correctly that I need to create one pipeline for every object due to the different shaders and in the command buffer have N draw calls for every object? (with binding of pipeline, ...)
[08:24:25] <it_> Also some programs do register the command buffers new for every frame, right? Otherwise how could I "add" an object when I only register them at initialization
[08:24:48] <it_> You could re-register them when objects are added or removed, but someone on stackoverflow said it's better to either always re-register them or never...?
[08:30:15] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-82s3g7l5qi77ye7huk9.18120a2.ip6.access.telenet.be> has joined ##vulkan
[08:33:42] *** ryp <ryp!~ryp@14.244.29.109.rev.sfr.net> has quit IRC (Ping timeout: 252 seconds)
[08:34:22] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-82s3g7l5qi77ye7huk9.18120a2.ip6.access.telenet.be> has quit IRC (Ping timeout: 245 seconds)
[08:55:06] *** Kingsqueeeee <Kingsqueeeee!~kingsquee@d162-156-55-229.bchsia.telus.net> has joined ##vulkan
[08:55:29] *** Kingsquee <Kingsquee!~kingsquee@d162-156-55-229.bchsia.telus.net> has quit IRC (Ping timeout: 260 seconds)
[08:55:30] *** xissburg <xissburg!~xissburg@unaffiliated/xissburg> has quit IRC (Quit: ZZZzzz…)
[08:57:11] *** ratchetfreak <ratchetfreak!c351a8d8@gateway/web/freenode/ip.195.81.168.216> has joined ##vulkan
[09:04:34] <Ralith> it's normal to use a fresh command buffer every frame, yes
[09:05:35] <it_> Ok, but they shouldn't be allocated though. Just vkCmdBeginCommandBuffer ... vkCmdEndCommandBuffer every frame?
[09:17:21] <Ralith> it's a good idea to reuse them when feasible, which isn't always
[09:18:19] <Ralith> be careful that you don't try to reuse a command buffer that the GPU might still be executing
[09:22:42] *** realitix <realitix!~realitix@92.103.166.6> has joined ##vulkan
[09:29:52] <it_> Ok so I should re-register the command buffers only when necessary?
[09:30:35] <it_> So like I would re-use them for 4000 frames, add a new object -> re-register, use those new command buffers for 8000 frames then delete that object -> re-register (or use the old ones if I still have them) ?
[09:31:01] <it_> But I understand this correctly that if I have 100 different objects each with different shaders, I'll be creating 100 pipelines ??
[09:31:35] *** davr0s <davr0s!~textual@host86-149-134-190.range86-149.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[09:34:47] <Ralith> very few applications need 100 different shaders
[09:37:58] <Yaniel> IIRC Just Cause 2 was hovering around 120
[09:38:03] <it_> Yes but this is more of a theoretical project I guess ....
[09:38:22] *** Salek <Salek!~salek@91-155-9-229.elisa-laajakaista.fi> has quit IRC (Ping timeout: 260 seconds)
[09:39:04] *** ratchetfreak <ratchetfreak!c351a8d8@gateway/web/freenode/ip.195.81.168.216> has quit IRC (Ping timeout: 260 seconds)
[09:39:07] <it_> Like make something like this in vulkan, probably "ugly" and then try to optimize it with vulkans' advantages
[09:39:21] <it_> Then the same in OpenGL and see how they perform or whatever...
[09:39:42] <it_> But for every different shader I have I would require a pipeline for it, right?
[09:42:19] <it_> What I have right now is 25x25 "different" objects. I have a command buffer in which I do foreach(object) { vkCmdPushConstants ... ; vkCmdDraw ... }
[09:43:14] *** davr0s <davr0s!~textual@host86-149-134-190.range86-149.btcentralplus.com> has joined ##vulkan
[09:43:17] <it_> It runs @ ~20 FPS (2MB model, no textures for now), but registering the commands seems to take ages...?
[09:43:43] <it_> Is this where I would use multiple threads to register the drawing commands in secondary command buffers...?
[10:01:18] *** realitix_ <realitix_!~realitix@92.103.166.6> has joined ##vulkan
[10:01:35] *** realitix_ <realitix_!~realitix@92.103.166.6> has quit IRC (Remote host closed the connection)
[10:01:48] *** realitix_ <realitix_!~realitix@92.103.166.6> has joined ##vulkan
[10:03:54] *** realitix <realitix!~realitix@92.103.166.6> has quit IRC (Ping timeout: 252 seconds)
[10:03:56] *** realitix_ is now known as realitix
[10:09:24] *** it_ <it_!b2c5eb1b@gateway/web/freenode/ip.178.197.235.27> has quit IRC (Ping timeout: 260 seconds)
[10:15:58] *** Kingsqueeeee <Kingsqueeeee!~kingsquee@d162-156-55-229.bchsia.telus.net> has quit IRC (Ping timeout: 264 seconds)
[10:31:02] *** davr0s <davr0s!~textual@host86-149-134-190.range86-149.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[10:48:52] *** realitix <realitix!~realitix@92.103.166.6> has quit IRC (Quit: realitix)
[10:49:04] *** realitix <realitix!~realitix@92.103.166.6> has joined ##vulkan
[10:55:17] *** davr0s <davr0s!~textual@host86-149-134-190.range86-149.btcentralplus.com> has joined ##vulkan
[11:02:29] *** davr0s <davr0s!~textual@host86-149-134-190.range86-149.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[11:08:05] *** Spotlight <Spotlight!~spotlight@spotlight0xff.me> has quit IRC (Ping timeout: 240 seconds)
[11:08:15] *** lucus16 <lucus16!~quassel@relto.rasusan.nl> has quit IRC (Ping timeout: 256 seconds)
[11:15:27] *** spotlight0xff <spotlight0xff!~spotlight@spotlight0xff.me> has joined ##vulkan
[11:19:58] *** Deluxe <Deluxe!~Deluxe@212.4.150.151> has joined ##vulkan
[11:30:57] <keith-man> try to reuse your command buffers creating them is generally slow
[11:31:04] <keith-man> you can sumbit them multiple times.
[11:52:39] *** Lucretia <Lucretia!~laguest@pdpc/supporter/active/lucretia> has quit IRC (Remote host closed the connection)
[11:52:57] *** Lucretia <Lucretia!~laguest@2a02:c7d:3c35:b000:325a:3aff:fe0f:37a5> has joined ##vulkan
[11:52:57] *** Lucretia <Lucretia!~laguest@2a02:c7d:3c35:b000:325a:3aff:fe0f:37a5> has quit IRC (Changing host)
[11:52:57] *** Lucretia <Lucretia!~laguest@pdpc/supporter/active/lucretia> has joined ##vulkan
[12:04:11] *** ratchetfreak <ratchetfreak!c351a8d8@gateway/web/freenode/ip.195.81.168.216> has joined ##vulkan
[13:03:04] *** slime <slime!~slime73@24.215.81.93> has joined ##vulkan
[13:12:15] *** slime <slime!~slime73@24.215.81.93> has quit IRC (Quit: This computer has gone to sleep)
[13:29:25] *** TSS_ <TSS_!~TSS@2a02:2f0a:4050:386:d250:99ff:fe83:4a0a> has quit IRC (Ping timeout: 245 seconds)
[13:52:22] *** mefesto <mefesto!~user@107.145.49.162> has joined ##vulkan
[14:11:36] *** daxar4 is now known as Daxar
[14:14:25] <Daxar> command buffer should really only have to change if vertex layout changes; if you just have some 3D models, you ought to just be able to update them with uniform buffer changes and leave the cmd buffer untouched each frame. Recreating the cmd buffer feels really wasteful if nothing has really changed
[14:17:35] <baldurk> for a real workload that's not really practical, since that doesn't allow for frustum culling, streaming, spawning and destroying dynamic objects, things like that. Even if you do your culling on the GPU with indirect draws command buffers will still likely be transient
[14:26:17] <mefesto> is it worthwhile to have cached command buffers for static geometry based on regions in the scene and ephemeral cbuffers for dynamic objects?
[14:27:35] <baldurk> I'd probably wait until you actually get bottlenecked on command buffer recording before worrying about that. Most likely, other things will be your worry long before you get to that point
[14:30:00] <exDM69> also worth noting that the performance characteristics depend on the hw and driver, even more so than with opengl
[14:30:14] <exDM69> so to get the best performance on all devices, you might need to have several paths to choose from
[14:30:30] <exDM69> but most likely you can just get away with doing the simple thing and it's going to be fast enough
[14:31:11] <exDM69> recording command buffers is pretty fast, probably not worth the effort trying to pre-record them for the majority of cases
[14:31:38] <mefesto> given that, VK_COMMAND_POOL_CREATE_TRANSIENT_BIT is the "typical" case?
[14:32:27] <mefesto> then just reset that pool when that frame is no longer in flight
[14:39:03] *** soulz <soulz!~soulz@unaffiliated/soulz> has quit IRC (Ping timeout: 256 seconds)
[14:45:54] *** sla_ro|master <sla_ro|master!~sla.ro@78.96.209.89> has joined ##vulkan
[14:46:35] *** soulz <soulz!~soulz@unaffiliated/soulz> has joined ##vulkan
[15:17:07] *** davr0s <davr0s!~textual@host86-149-134-190.range86-149.btcentralplus.com> has joined ##vulkan
[15:25:23] *** soulz <soulz!~soulz@unaffiliated/soulz> has quit IRC (Quit: leaving)
[15:37:01] *** cheakoirccloud <cheakoirccloud!uid293319@gateway/web/irccloud.com/x-lgickatonqhynwxj> has joined ##vulkan
[15:47:39] *** soulz <soulz!~soulz@unaffiliated/soulz> has joined ##vulkan
[15:52:35] *** davr0s <davr0s!~textual@host86-149-134-190.range86-149.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[16:10:08] *** james <james!~james@static-96-43-65-242.albyny.csvoip.net> has joined ##vulkan
[16:10:31] *** james is now known as Guest71884
[16:11:00] *** borkr <borkr!~borkr@static130-244.mimer.net> has joined ##vulkan
[16:11:46] *** borkr <borkr!~borkr@static130-244.mimer.net> has quit IRC (Remote host closed the connection)
[16:15:12] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has joined ##vulkan
[16:21:21] *** grouse <grouse!~grouse@83-233-9-2.cust.bredband2.com> has quit IRC (Quit: Leaving)
[16:58:07] *** davr0s <davr0s!~textual@host86-149-134-190.range86-149.btcentralplus.com> has joined ##vulkan
[17:35:22] *** davr0s <davr0s!~textual@host86-149-134-190.range86-149.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[17:50:29] *** realitix <realitix!~realitix@92.103.166.6> has quit IRC (Quit: realitix)
[18:01:46] *** hlmjr <hlmjr!~herb@c-76-120-173-141.hsd1.pa.comcast.net> has quit IRC (Quit: Konversation terminated!)
[18:10:53] *** d3x0r <d3x0r!~d3x0r@ip174-72-226-164.lv.lv.cox.net> has quit IRC (Read error: Connection reset by peer)
[18:11:54] *** d3x0r <d3x0r!~d3x0r@ip174-72-226-164.lv.lv.cox.net> has joined ##vulkan
[18:36:46] <dyl> Anyone have any thoughts on VkHPPs UniqueHandlers?
[18:36:49] <dyl> UniqueHandles*
[18:40:24] *** ratchetfreak <ratchetfreak!c351a8d8@gateway/web/freenode/ip.195.81.168.216> has quit IRC (Ping timeout: 260 seconds)
[18:45:59] *** random_james_awy is now known as random_james
[18:56:02] *** davr0s <davr0s!~textual@host86-149-134-190.range86-149.btcentralplus.com> has joined ##vulkan
[19:15:14] *** soul-d <soul-d!~uknown@2a02:a44a:bcae:1:7d7e:449f:dad4:eaf2> has quit IRC (Read error: Connection reset by peer)
[19:15:39] *** soul-d <soul-d!~uknown@2a02:a44a:bcae:1:7d7e:449f:dad4:eaf2> has joined ##vulkan
[19:17:42] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-82s3g7l5qi77ye7huk9.18120a2.ip6.access.telenet.be> has joined ##vulkan
[19:25:23] *** d3x0r <d3x0r!~d3x0r@ip174-72-226-164.lv.lv.cox.net> has quit IRC (Read error: Connection reset by peer)
[19:25:58] *** mefesto` <mefesto`!~user@107.145.49.162> has joined ##vulkan
[19:26:24] *** d3x0r <d3x0r!~d3x0r@ip174-72-226-164.lv.lv.cox.net> has joined ##vulkan
[19:27:10] *** mefesto <mefesto!~user@107.145.49.162> has quit IRC (Ping timeout: 256 seconds)
[19:27:18] *** mefesto` is now known as mefesto
[19:32:46] *** xissburg <xissburg!~xissburg@unaffiliated/xissburg> has joined ##vulkan
[19:53:40] <dyl> What's going on here?
[19:53:48] <dyl> Undefined symbols for architecture x86_64: "_vkDestroyDebugReportCallbackEXT"
[19:53:51] <dyl> I wasn't seeing this before.
[19:54:36] <turol> that's an extension function
[19:54:48] <turol> you must load it dynamically
[19:54:53] <dyl> So, it appears it's declared but not defined?
[19:54:58] <turol> yes
[19:55:10] <dyl> Is it safe to just define the ones I want in my own engine/library?
[19:55:15] <turol> yes
[19:55:18] <dyl> Perfect.
[19:55:28] <turol> but not recommended
[19:55:36] <dyl> What is recommended?
[19:55:48] <turol> https://github.com/turol/smaaDemo/blob/master/renderer/VulkanRenderer.cpp#L34
[19:55:48] <dyl> I'm trying to abstract vulkan away from the user as much as possible (save the necessity of obtaining a surface/instance pair).
[19:56:05] <turol> if you're using vulkan.hpp there's a dynamic dispatcher in there
[19:56:14] <dyl> I am.
[19:56:15] <turol> if you're using vulkan.h, just use function pointers
[19:56:23] <dyl> This wasn't happening until I was using .hpp weirdly enough.
[19:56:32] <dyl> It just started happening as I switched some stuff over to UniqueHandles.
[19:56:44] <dyl> It wasn't happening at first using vulkan.hpp either.
[19:56:54] <turol> were you calling the destroy function yourself?
[19:57:09] <dyl> I wasn't at the point of even doing the destroy cleanup yet, so that's probably why.
[19:57:20] <turol> well there's your problem
[19:57:27] <dyl> I'm still wading through boilerplate. I went through the tutorial separately, and am now putting things together in my own project.
[19:57:27] <turol> the uniquehandle calls the destructor for you
[19:57:45] <dyl> So, what ought I to do with DispatchLoaderDynamic?
[19:58:09] <dyl> "To use Vulkan-Hpp with extensions it's required to have either a library which provides stubs to all used Vulkan functions or to tell Vulkan-Hpp to dispatch those functions pointers."
[19:58:15] <turol> haven't used it myself yet
[19:58:32] <turol> but in theory you load it up with the extension pointers and then pass it to every call
[19:58:39] <dyl> Ah, now I see where the dispatch parameter is coming in.
[19:58:58] <dyl> I was wondering about that.
[19:59:30] <dyl> It's a little odd to me that Device::waitIdle(Dispatch const &d ) can be called as device->waitIdle()
[19:59:39] <dyl> without any explicit Dispatch given.
[19:59:59] <turol> it's probably defaulted
[20:00:16] <dyl> I would assume that, but I don't see the default.
[20:00:28] <dyl> Ah wait no I found it.
[20:00:31] <turol> or there's another overload which takes no parameters
[20:01:59] <dyl> But... how would that work in the case of a UniqueHandle?
[20:02:05] <dyl> How is it supposed to know which dispatch to use?
[20:02:13] <dyl> It's not a constructor parameter either.
[20:02:40] <turol> i think the uniquehandle keeps a pointer to the destructor function
[20:03:26] *** ryp <ryp!~ryp@14.244.29.109.rev.sfr.net> has joined ##vulkan
[20:03:48] <dyl> It does, which is defaulted.
[20:04:12] <turol> and the default loader assumes that you have provided a stub for the extension function
[20:04:22] <turol> which would call the real function via pointer
[20:04:25] <dyl> create*Unique does take a dispatch parameter.
[20:04:31] <turol> since you haven't, undefined reference
[20:04:32] <dyl> The default is DispatchLoaderStatic, yeah.
[20:04:44] <dyl> The confusing bit for me is that because I'm working with GLFW for this demo,
[20:05:08] <dyl> I have to use VkSurfaceKHR, and then when I construct Engine I do
[20:05:19] <dyl> vkmol::Engine Engine{vk::UniqueInstance(Instance), vk::UniqueSurfaceKHR(Surface)} (it's a most vexing parse)
[20:05:36] <dyl> But this constructor does *not* take any kind of Dispatch.
[20:05:47] <dyl> It does appear every *method* on a UniqueHandle does take a Dispatch however.
[20:06:13] <dyl> Ah, okay now I see. It would break the bridging if the UniqueHandle carried the dispatch as state.
[20:06:22] <dyl> You just have to pass it, it seems.
[20:06:41] <dyl> In this case, for now, I'm going to just use static dispatch I think.
[20:07:36] <dyl> One issue I can see with this is that if you use the Dispatch parameter, since it's the *last* parameter, you forgo default parameters *in every single Vulkan method call*.
[20:07:38] <dyl> That seems like quite a penalty.
[20:19:30] *** derhass <derhass!~derhass@ipservice-092-208-157-142.092.208.pools.vodafone-ip.de> has joined ##vulkan
[20:21:11] <dyl> Looks like this is one approach: https://github.com/KhronosGroup/Vulkan-Docs/blob/1.0/src/ext_loader/vulkan_ext.c
[20:27:08] *** MrFlibble <MrFlibble!~Flibble@2.122.47.217> has joined ##vulkan
[20:28:04] *** Kingsquee <Kingsquee!~kingsquee@d162-156-55-229.bchsia.telus.net> has joined ##vulkan
[20:33:51] <Daxar> I thought GLFW had a way to dynamically bind Vulkan functions for you?
[20:35:29] *** MrFlibble <MrFlibble!~Flibble@2.122.47.217> has quit IRC (Disconnected by services)
[20:35:30] *** MrFlibble2 <MrFlibble2!MrFlibble@2.122.47.217> has joined ##vulkan
[20:53:48] <dyl> I don't recall seeing any of that.
[20:58:51] <dyl> Daxar: GLFW to my knowledge just tells you what extensions it needs (KHR_surface and whatever is specific to a particular platform).
[20:59:18] <dyl> The odd thing is that I never had to load things like KHRDestroySurface before.
[20:59:29] <dyl> But now I’m getting segfaults at exit.
[20:59:52] <dyl> I think this is again due to using the UniqueHandles.
[21:03:01] *** halbeno <halbeno!~halbeno@node-1w7jra22dpc6yrvo9wam83mu0.ipv6.telus.net> has quit IRC (Remote host closed the connection)
[21:03:20] *** halbeno <halbeno!~halbeno@node-1w7jra22dpc6yrvo9wam83mu0.ipv6.telus.net> has joined ##vulkan
[21:03:33] <dyl> At least when Vulkan erupts in your face it’s relatively not black boxy.
[21:04:40] *** jdashg <jdashg!~jdashg@corp-nat.fw1.untrust.mtv2.mozilla.net> has joined ##vulkan
[21:06:23] *** MrFlibble2 <MrFlibble2!MrFlibble@2.122.47.217> has left ##vulkan
[21:07:46] <dyl> Well this is annoying.
[21:08:18] <dyl> Before I never had to populate vkDestroySurfaceKHR manually :/.
[21:08:43] *** Salek <Salek!~salek@91-155-9-229.elisa-laajakaista.fi> has joined ##vulkan
[21:09:56] <dyl> VK_KHR_surface *is* an extension I suppose.
[21:11:01] <dyl> I guess I need to use genvk.py vulkan_ext.c and remove the WSI extensions?
[21:12:27] <dyl> "We will be removing vulkan_ext.[ch] in the next spec update. As @krOoze notes, it has conflicts with the loader, and other significant limitations. Since people may still want to use it, we'll be keeping the generator code that creates these files from vk.xml, but not supporting it going forward."
[21:12:31] <dyl> Ah, well, there goes that.
[21:14:52] <dyl> It appears that DispatchLoaderStatic simply doesn't handle vkDestroyDebugCallbackEXT, so my only options would be:
[21:15:04] <dyl> 1) Don't use UniqueDebugReportCallbackEXT, just manually destruct it.
[21:15:22] <dyl> 2) Use a dynamic loader (which has major penalties).
[21:15:58] <dyl> 3) Define _vkDestroyDebugReportCallbackEXT myself (which would potentially break).
[21:16:01] <dyl> So, #1 it is!
[21:23:45] *** nsf <nsf!~nsf@jiss.convex.ru> has quit IRC (Quit: WeeChat 2.1)
[21:24:40] *** rodarmor <rodarmor!sid210835@gateway/web/irccloud.com/x-zrwknqumqabzzocx> has quit IRC ()
[21:25:35] *** rodarmor <rodarmor!sid210835@gateway/web/irccloud.com/x-tcjkgflitnihyxmp> has joined ##vulkan
[21:30:00] <dyl> Had a fancy little idea:
[21:30:19] <dyl> Rather than try force the user to interleave obtaining an instance and using it to get a surface, then having them provide both...
[21:30:30] <dyl> Why not just have them provide a lambda that given an instance provides me the surface?
[21:30:35] <dyl> :\
[21:32:00] *** MrFlibble <MrFlibble!~Flibble@2.122.47.217> has joined ##vulkan
[21:32:46] *** MrFlibble2 <MrFlibble2!MrFlibble@2.122.47.217> has joined ##vulkan
[21:33:58] *** Oxyd is now known as Guest65014
[21:34:21] *** MrFlibble <MrFlibble!~Flibble@2.122.47.217> has quit IRC (Disconnected by services)
[21:35:59] *** Guest65014 is now known as Oxyd
[21:38:36] *** Deluxe_ <Deluxe_!~Deluxe@212.4.150.151> has joined ##vulkan
[21:38:50] *** Deluxe_ <Deluxe_!~Deluxe@212.4.150.151> has quit IRC (Read error: Connection reset by peer)
[21:39:36] *** clintar <clintar!~clintar@68.69.164.130> has quit IRC (Quit: Leaving)
[21:40:18] *** lostgoat <lostgoat!~quassel@40.ip-167-114-115.net> has quit IRC (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
[21:40:56] *** Deluxe_ <Deluxe_!~Deluxe@212.4.150.151> has joined ##vulkan
[21:41:07] *** glYoda <glYoda!~MTLYoda@c-73-25-27-206.hsd1.or.comcast.net> has quit IRC (Quit: glYoda)
[21:42:05] *** Deluxe <Deluxe!~Deluxe@212.4.150.151> has quit IRC (Ping timeout: 240 seconds)
[21:45:52] *** lostgoat <lostgoat!~quassel@40.ip-167-114-115.net> has joined ##vulkan
[22:03:36] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has quit IRC (Quit: Leaving)
[22:07:51] *** sharpneli <sharpneli!sharpneli@hilla.kapsi.fi> has quit IRC (Ping timeout: 256 seconds)
[22:07:58] *** sharpneli <sharpneli!sharpneli@hilla.kapsi.fi> has joined ##vulkan
[22:18:24] *** nsf <nsf!~nsf@jiss.convex.ru> has joined ##vulkan
[22:21:58] *** halbeno_ <halbeno_!~halbeno@node-1w7jra22dpc6yrvo9wam83mu0.ipv6.telus.net> has joined ##vulkan
[22:22:12] *** halbeno <halbeno!~halbeno@node-1w7jra22dpc6yrvo9wam83mu0.ipv6.telus.net> has quit IRC (Read error: Connection reset by peer)
[23:02:34] *** Deluxe_ <Deluxe_!~Deluxe@212.4.150.151> has quit IRC (Read error: Connection reset by peer)
[23:03:53] *** Deluxe <Deluxe!~Deluxe@212.4.150.151> has joined ##vulkan
[23:04:36] <dyl> Weird. Notched corners are back.
[23:04:36] <dyl> As soon as I install validation layers...?
[23:09:07] *** sla_ro|master <sla_ro|master!~sla.ro@78.96.209.89> has quit IRC ()
[23:10:30] *** nsf <nsf!~nsf@jiss.convex.ru> has quit IRC (Quit: WeeChat 2.1)
top

   May 24, 2018
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31