June 11, 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 | >
June 11, 2018 [00:00:06] <HZun> anyway thanks for the help guys. i am gonna think a bit about the while pre-emption vs spatial-multitasking tradeoff :)[00:00:14] *** cramalho <cramalho!~cramalho@179.190.254.211> has quit IRC (Quit: cramalho)[00:00:15] <sharpneli> An implementer can easily make it so that the different queues work like that[00:00:17] <HZun> whole*[00:01:40] <HZun> Yeah i was a bad example :D[00:01:44] <HZun> it*[00:03:02] <HZun> its actually the other way around.[00:03:23] <HZun> in opengl the driver developers can do all sorts of optimizations.[00:04:16] <HZun> but it seems like with vulkan the driver developers dont want to do too many "magic" optimizations (at least thats how i understand it from various readings). and instead want the application developers to be explicit about what they want.[00:04:41] <HZun> thus it would make sense if Vulkan support being explicit about wanting spatial multi-tasking or not, etc.[00:05:01] <HZun> atleast in my mind :)[00:11:27] *** HZun <HZun!~HZun@0x3ec72d49.osd.customer.dk.telia.net> has quit IRC (Ping timeout: 240 seconds)[00:13:21] *** cramalho <cramalho!~cramalho@2804:54:16f5:8200:bd67:9a34:7fbd:ea22> has joined ##vulkan[00:36:57] *** cheakoirccloud <cheakoirccloud!uid293319@gateway/web/irccloud.com/x-picfmupkxngcrchq> has quit IRC (Quit: Connection closed for inactivity)[00:44:05] *** cramalho <cramalho!~cramalho@2804:54:16f5:8200:bd67:9a34:7fbd:ea22> has quit IRC (Remote host closed the connection)[00:45:41] *** davr0s <davr0s!~textual@host86-157-70-142.range86-157.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[00:48:47] *** cramalho <cramalho!~cramalho@179.190.254.211> has joined ##vulkan[00:51:29] *** watered <watered!~dagger@gateway/tor-sasl/watered> has quit IRC (Ping timeout: 250 seconds)[01:09:31] *** soulz <soulz!~soulz@unaffiliated/soulz> has quit IRC (Quit: leaving)[01:12:26] *** soulz <soulz!~soulz@unaffiliated/soulz> has joined ##vulkan[01:39:19] *** ville_ <ville_!~ville@37-136-13-131.rev.dnainternet.fi> has joined ##vulkan[01:40:21] *** ville <ville!~ville@37-136-13-131.rev.dnainternet.fi> has quit IRC (Ping timeout: 256 seconds)[01:40:28] *** ville_ is now known as ville[01:54:22] *** MrFlibble <MrFlibble!MrFlibble@2.122.47.217> has quit IRC (Ping timeout: 264 seconds)[02:26:21] *** ratchet_freak <ratchet_freak!~ratchetfr@ptr-82s3g7nu9uak27g24h0.18120a2.ip6.access.telenet.be> has quit IRC (Ping timeout: 240 seconds)[03:38:23] *** salamanderrake <salamanderrake!~quassel@cpe-24-165-202-54.neo.res.rr.com> has quit IRC (Remote host closed the connection)[03:39:11] *** salamanderrake <salamanderrake!~quassel@cpe-24-165-202-54.neo.res.rr.com> has joined ##vulkan[03:40:33] *** cramalho <cramalho!~cramalho@179.190.254.211> has quit IRC (Remote host closed the connection)[03:43:35] *** cramalho <cramalho!~cramalho@179.190.254.211> has joined ##vulkan[05:07:26] <rotaerk> finally, almost to the actual drawing of a triangle...[05:08:00] <rotaerk> I've finished with the pipeline creation ... about 1000 lines of haskell code and still no triangle[05:08:10] <rotaerk> crazy[05:32:40] *** slime <slime!~slime73@blk-215-81-93.eastlink.ca> has quit IRC (Quit: This computer has gone to sleep)[07:30:19] *** nsf <nsf!~nsf@jiss.convex.ru> has joined ##vulkan[07:32:10] *** davr0s <davr0s!~textual@host86-157-70-142.range86-157.btcentralplus.com> has joined ##vulkan[08:01:51] *** snyp <snyp!~Snyp@103.56.236.91> has joined ##vulkan[08:06:30] *** davr0s <davr0s!~textual@host86-157-70-142.range86-157.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[08:10:35] *** snyp <snyp!~Snyp@103.56.236.91> has quit IRC (Ping timeout: 256 seconds)[08:12:51] *** mandeep_ <mandeep_!mandeep@gateway/vpn/privateinternetaccess/mandeepb> has quit IRC (Ping timeout: 256 seconds)[08:22:07] *** Deluxe <Deluxe!~Deluxe@2001:67c:1220:80e:e9:1d2:f14f:e47f> has joined ##vulkan[08:40:40] *** grouse <grouse!~grouse@83-233-9-2.cust.bredband2.com> has joined ##vulkan[08:48:47] *** xissburg <xissburg!~xissburg@unaffiliated/xissburg> has quit IRC (Quit: ZZZzzz…)[09:03:23] *** watered <watered!~dagger@gateway/tor-sasl/watered> has joined ##vulkan[09:04:36] *** Guest4630 <Guest4630!4d3b9548@gateway/web/cgi-irc/kiwiirc.com/ip.77.59.149.72> has joined ##vulkan[09:06:56] *** Guest4630 <Guest4630!4d3b9548@gateway/web/cgi-irc/kiwiirc.com/ip.77.59.149.72> has quit IRC (Client Quit)[09:07:12] *** borkr <borkr!~borkr@static130-244.mimer.net> has joined ##vulkan[09:07:14] *** Guest4630 <Guest4630!4d3b9548@gateway/web/cgi-irc/kiwiirc.com/ip.77.59.149.72> has joined ##vulkan[09:09:30] *** bridger <bridger!~dagger@gateway/tor-sasl/watered> has joined ##vulkan[09:10:41] *** watered <watered!~dagger@gateway/tor-sasl/watered> has quit IRC (Ping timeout: 250 seconds)[09:18:12] *** Yamakaja <Yamakaja!~yamakaja@vps.pub.yamakaja.me> has quit IRC (Quit: Bye)[09:20:14] *** Yamakaja <Yamakaja!~yamakaja@vps.pub.yamakaja.me> has joined ##vulkan[09:20:51] *** watered <watered!~dagger@gateway/tor-sasl/watered> has joined ##vulkan[09:22:49] *** bridger <bridger!~dagger@gateway/tor-sasl/watered> has quit IRC (Ping timeout: 250 seconds)[09:28:29] *** bridger <bridger!~dagger@gateway/tor-sasl/watered> has joined ##vulkan[09:31:03] *** watered <watered!~dagger@gateway/tor-sasl/watered> has quit IRC (Ping timeout: 250 seconds)[09:31:06] *** watered_ <watered_!~dagger@gateway/tor-sasl/watered> has joined ##vulkan[09:33:39] *** bridger <bridger!~dagger@gateway/tor-sasl/watered> has quit IRC (Ping timeout: 250 seconds)[09:38:00] *** watered <watered!~dagger@gateway/tor-sasl/watered> has joined ##vulkan[09:40:35] *** watered_ <watered_!~dagger@gateway/tor-sasl/watered> has quit IRC (Ping timeout: 250 seconds)[09:44:02] <neure> thats vulkan for you[09:44:03] *** watered <watered!~dagger@gateway/tor-sasl/watered> has quit IRC (Ping timeout: 250 seconds)[09:51:02] *** bridger <bridger!~dagger@gateway/tor-sasl/watered> has joined ##vulkan[09:54:44] *** watered <watered!~dagger@gateway/tor-sasl/watered> has joined ##vulkan[09:57:03] *** bridger <bridger!~dagger@gateway/tor-sasl/watered> has quit IRC (Ping timeout: 250 seconds)[10:05:55] *** bridger <bridger!~dagger@gateway/tor-sasl/watered> has joined ##vulkan[10:08:19] *** watered <watered!~dagger@gateway/tor-sasl/watered> has quit IRC (Ping timeout: 250 seconds)[10:14:43] *** davr0s <davr0s!~textual@host86-157-70-142.range86-157.btcentralplus.com> has joined ##vulkan[10:19:20] *** watered <watered!~dagger@gateway/tor-sasl/watered> has joined ##vulkan[10:22:11] *** bridger <bridger!~dagger@gateway/tor-sasl/watered> has quit IRC (Ping timeout: 250 seconds)[10:24:55] *** ratchetfreak <ratchetfreak!c351a8d8@gateway/web/freenode/ip.195.81.168.216> has joined ##vulkan[10:25:40] *** bridger <bridger!~dagger@gateway/tor-sasl/watered> has joined ##vulkan[10:28:41] *** watered <watered!~dagger@gateway/tor-sasl/watered> has quit IRC (Ping timeout: 250 seconds)[10:38:37] *** Guest4630 <Guest4630!4d3b9548@gateway/web/cgi-irc/kiwiirc.com/ip.77.59.149.72> has quit IRC (Ping timeout: 260 seconds)[10:45:58] *** davr0s <davr0s!~textual@host86-157-70-142.range86-157.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[10:48:51] *** watered <watered!~dagger@gateway/tor-sasl/watered> has joined ##vulkan[10:51:13] *** bridger <bridger!~dagger@gateway/tor-sasl/watered> has quit IRC (Ping timeout: 250 seconds)[10:55:51] *** herbmillerjr <herbmillerjr!~herb@c-76-120-173-141.hsd1.pa.comcast.net> has quit IRC (Read error: Connection reset by peer)[10:58:32] *** herbmillerjr <herbmillerjr!~herb@c-76-120-173-141.hsd1.pa.comcast.net> has joined ##vulkan[10:59:30] *** herbmillerjr <herbmillerjr!~herb@c-76-120-173-141.hsd1.pa.comcast.net> has quit IRC (Client Quit)[11:33:28] *** bridger <bridger!~dagger@gateway/tor-sasl/watered> has joined ##vulkan[11:33:59] *** herbmillerjr <herbmillerjr!~herb@c-76-120-173-141.hsd1.pa.comcast.net> has joined ##vulkan[11:35:51] *** watered <watered!~dagger@gateway/tor-sasl/watered> has quit IRC (Ping timeout: 250 seconds)[11:39:41] *** herbmillerjr <herbmillerjr!~herb@c-76-120-173-141.hsd1.pa.comcast.net> has quit IRC (Ping timeout: 256 seconds)[11:41:39] *** herbmillerjr <herbmillerjr!~herb@c-76-120-173-141.hsd1.pa.comcast.net> has joined ##vulkan[11:41:54] *** Guest4630 <Guest4630!4d3b9548@gateway/web/cgi-irc/kiwiirc.com/ip.77.59.149.72> has joined ##vulkan[11:56:53] *** herbmillerjr <herbmillerjr!~herb@c-76-120-173-141.hsd1.pa.comcast.net> has quit IRC (Ping timeout: 256 seconds)[11:58:14] *** watered <watered!~dagger@gateway/tor-sasl/watered> has joined ##vulkan[12:00:07] *** bridger <bridger!~dagger@gateway/tor-sasl/watered> has quit IRC (Ping timeout: 250 seconds)[12:03:14] *** bridger <bridger!~dagger@gateway/tor-sasl/watered> has joined ##vulkan[12:05:19] *** watered <watered!~dagger@gateway/tor-sasl/watered> has quit IRC (Ping timeout: 250 seconds)[12:05:30] *** herbmillerjr <herbmillerjr!~herb@c-76-120-173-141.hsd1.pa.comcast.net> has joined ##vulkan[12:06:25] *** watered <watered!~dagger@gateway/tor-sasl/watered> has joined ##vulkan[12:09:13] *** bridger <bridger!~dagger@gateway/tor-sasl/watered> has quit IRC (Ping timeout: 250 seconds)[12:26:07] *** watered <watered!~dagger@gateway/tor-sasl/watered> has quit IRC (Ping timeout: 250 seconds)[12:26:55] *** sp3ctrum <sp3ctrum!~textual@77.210.219.8> has joined ##vulkan[12:37:04] *** sp3ctrum <sp3ctrum!~textual@77.210.219.8> has quit IRC (Quit: Textual IRC Client: www.textualapp.com)[13:02:28] *** slime <slime!~slime73@24.215.81.93> has joined ##vulkan[13:21:20] *** slime <slime!~slime73@24.215.81.93> has quit IRC (Quit: This computer has gone to sleep)[14:01:50] *** davr0s <davr0s!~textual@host86-157-70-142.range86-157.btcentralplus.com> has joined ##vulkan[14:16:07] *** nsf <nsf!~nsf@jiss.convex.ru> has quit IRC (Quit: WeeChat 2.1)[14:52:44] *** davr0s <davr0s!~textual@host86-157-70-142.range86-157.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[15:29:23] *** kasumi-owari <kasumi-owari!~kasumi-ow@ftth-213-233-237-007.solcon.nl> has quit IRC (Ping timeout: 256 seconds)[15:31:24] *** kasumi-owari <kasumi-owari!~kasumi-ow@ftth-213-233-237-007.solcon.nl> has joined ##vulkan[15:38:52] *** davr0s <davr0s!~textual@host86-157-70-142.range86-157.btcentralplus.com> has joined ##vulkan[16:01:16] *** sla_ro|master <sla_ro|master!~sla.ro@78.96.209.89> has joined ##vulkan[16:06:39] *** MrCooper <MrCooper!~MrCooper@2a02:120b:7fe:4fc0:3a63:bbff:feca:3701> has quit IRC (Remote host closed the connection)[16:09:51] *** MrCooper <MrCooper!~MrCooper@2a02:120b:7fe:4fc0:3a63:bbff:feca:3701> has joined ##vulkan[16:12:17] *** MrCooper <MrCooper!~MrCooper@2a02:120b:7fe:4fc0:3a63:bbff:feca:3701> has quit IRC (Remote host closed the connection)[16:12:32] *** MrCooper <MrCooper!~MrCooper@2a02:120b:7fe:4fc0:8f54:9367:3609:f1a8> has joined ##vulkan[16:17:26] *** davr0s <davr0s!~textual@host86-157-70-142.range86-157.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[16:21:04] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has joined ##vulkan[16:29:48] *** Hadriscus <Hadriscus!Hadriscus@2a01:e35:2ebe:12f0:c167:e879:95e8:132e> has joined ##vulkan[16:37:53] *** Deluxe <Deluxe!~Deluxe@2001:67c:1220:80e:e9:1d2:f14f:e47f> has quit IRC (Remote host closed the connection)[16:43:34] *** grouse <grouse!~grouse@83-233-9-2.cust.bredband2.com> has quit IRC (Quit: Leaving)[16:45:06] *** davr0s <davr0s!~textual@host86-157-70-142.range86-157.btcentralplus.com> has joined ##vulkan[17:01:19] *** ector <ector!~asdf@ua-85-224-236-175.bbcust.telenor.se> has joined ##vulkan[17:04:55] *** nsf <nsf!~nsf@jiss.convex.ru> has joined ##vulkan[17:26:01] <dyl> rotaerk same here :|[17:26:10] <dyl> ~1200 lines of C++ and I have a fully functional black screen.[17:26:14] <dyl> Hey, at least it's clearing![17:36:44] *** davr0s <davr0s!~textual@host86-157-70-142.range86-157.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[17:38:16] <ratchetfreak> clearing to a different color should be simple now[17:38:49] <dyl> Interesting.[17:39:02] <dyl> If I load MoltenVK to enable debug mode, and also turn on the watermark,[17:39:10] <dyl> I see the watermark... having a seizure across the window.[17:40:27] <dyl> Considering here the vertex data for the triangle is in the shader, I'm assuming some kind of bad shader conversion...?[17:44:14] <dyl> I assume the watermark just has a random position each frame, and that’s why.[17:44:27] <dyl> So, at least I know the window/surface/etc CAN draw...?[17:45:08] <dyl> rotaerk: don’t worry, once you actually get something drawn, it gets easier :p.[17:45:43] <dyl> Then you can do camera control... chrisf is super knowledgeable about arcball implementation. :-)[17:49:08] <chrisf> dyl: argh.[17:56:42] <dyl> Yarr, matey.[18:10:00] *** xissburg <xissburg!~xissburg@unaffiliated/xissburg> has joined ##vulkan[18:20:21] *** nsf <nsf!~nsf@jiss.convex.ru> has quit IRC (Quit: WeeChat 2.1)[18:23:29] *** ColaEuphoria <ColaEuphoria!~ColaEupho@unaffiliated/colaeuphoria> has quit IRC (Ping timeout: 276 seconds)[18:26:09] *** Ralith_ <Ralith_!~ralith@c-24-143-116-108.customer.broadstripe.net> has quit IRC (Ping timeout: 264 seconds)[18:27:49] *** Ralith_ <Ralith_!~ralith@c-24-143-116-108.customer.broadstripe.net> has joined ##vulkan[18:30:04] *** Deluxe <Deluxe!~Deluxe@212.4.150.151> has joined ##vulkan[18:31:59] <dyl> Not sure how to go about debugging my black screen, any suggestions?[18:32:14] <dyl> I'm not getting any validation issues, or any issues from the MoltenVK debug mode (though it's also not printing the shader conversions to MSL...)[18:33:40] *** MrFlibble <MrFlibble!MrFlibble@2.122.47.217> has joined ##vulkan[18:34:24] *** ratchetfreak <ratchetfreak!c351a8d8@gateway/web/freenode/ip.195.81.168.216> has quit IRC (Ping timeout: 260 seconds)[18:35:20] *** ColaEuphoria <ColaEuphoria!~ColaEupho@unaffiliated/colaeuphoria> has joined ##vulkan[18:35:49] *** cramalho <cramalho!~cramalho@179.190.254.211> has quit IRC (Remote host closed the connection)[18:41:34] <turol> dyl: renderdoc[18:42:31] <baldurk> if they're using MoltenVK that isn't possible[18:42:40] *** davr0s <davr0s!~textual@host86-157-70-142.range86-157.btcentralplus.com> has joined ##vulkan[18:42:42] <dyl> ^[18:43:29] <dyl> Checked shader conversion, looks all kosher.[18:46:21] <dyl> I'm more wondering what makes sense to check setup/init wise.[18:46:33] <dyl> I was thinking the shaders themselves, but perhaps it's my pipeline?[18:47:05] <dyl> (if anyone is feeling unreasonably charitable, the code is here: https://github.com/DylanLukes/VkMOL/blob/master/src/vkmol/src/engine/Engine.cpp)[18:47:59] *** davr0s <davr0s!~textual@host86-157-70-142.range86-157.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[18:51:55] <dyl> Oh, there it is haha.[18:52:06] <dyl> The tutorial uses clockwise for front face. I use CCW.[18:52:09] <dyl> Cool, it draws.[18:52:36] <dyl> I finally got a triangle in Vulkan! 🎺[18:55:53] *** herbmillerjr <herbmillerjr!~herb@c-76-120-173-141.hsd1.pa.comcast.net> has quit IRC (Quit: Konversation terminated!)[18:57:37] *** Guest4630 <Guest4630!4d3b9548@gateway/web/cgi-irc/kiwiirc.com/ip.77.59.149.72> has quit IRC (Ping timeout: 248 seconds)[19:04:17] *** davr0s <davr0s!~textual@host86-157-70-142.range86-157.btcentralplus.com> has joined ##vulkan[19:14:45] *** watered <watered!~dagger@gateway/tor-sasl/watered> has joined ##vulkan[19:35:46] *** ratchet_freak <ratchet_freak!~ratchetfr@ptr-82s3g7nu9uak27g24h0.18120a2.ip6.access.telenet.be> has joined ##vulkan[19:45:45] *** ville <ville!~ville@37-136-13-131.rev.dnainternet.fi> has quit IRC (Ping timeout: 260 seconds)[19:48:24] *** ville <ville!~ville@37-136-113-215.rev.dnainternet.fi> has joined ##vulkan[19:55:48] <dyl> Nothing the tutorial here:[19:55:50] <dyl> "We could recreate the command pool from scratch, but that is rather wasteful. Instead I've opted to clean up the existing command buffers with the vkFreeCommandBuffers function. This way we can reuse the existing pool to allocate the new command buffers."[19:56:18] <dyl> I care more about consistency with C++ memory management (this is code for other people, not for my own use), so I'm using UniqueHandles to keep RAII-ness.[19:56:35] <dyl> How bad is the overhead of recreating the command pool?[19:56:56] <dyl> e.g. what if I just recreated the command pool to trigger a cascade of deletes (avoiding any manual freeing)?[19:58:36] <dyl> Is it really that wasteful? And are there any caveats or other reasons why you might want a fresh pool anyways?[19:59:20] <ector> that'll entirely depend on the driver, but recreating stuff like pools shouldn't be done every frame if you can avoid it. one good pattern is to vkResetCommandPool and then re-record your command buffers, if you re-record them every frame (and swap between two or three pools, of course, so you can keep multiple frames in flight). this might not be so pretty RAII-wise though[20:01:02] <dyl> I’m only recreating for out of date swapchains right now.[20:01:18] <dyl> I’m also wondering: what happens when you have a change of dpi or device?[20:01:31] <dyl> I.e. I move a window onto a secondary monitor with a lower ppi*[20:01:47] <dyl> Or, I force change the current GPU in use (on Mac)[20:01:56] <dyl> (Or it changes due to low power.)[20:02:07] <dyl> Is there some equivalent notification to recreate the logical device?[20:04:43] <chrisf> dyl: only the window system cares about ppi, if you need to do anything it will be recreating the swapchain[20:05:02] <dyl> Excellent.[20:05:37] <chrisf> no idea how moltenvk handles switching GPUs[20:06:06] <chrisf> it may just work, or you may lose your device, or you may just see both GPUs[20:06:10] <dyl> I do not know either.[20:06:25] <dyl> Change in ppi is expressed as a window size event, roughly. So that bit isn’t too bad.[20:07:07] *** mauz555 <mauz555!~mauz555@cpe-142-129-115-205.socal.res.rr.com> has joined ##vulkan[20:07:32] <dyl> I know that in general when an application is using the discrete GPU the system locks to it.[20:07:49] <dyl> I’m not sure how some things switch seamlessly.[20:09:59] <dyl> https://developer.apple.com/documentation/metal/advanced_techniques/device_selection_and_fallback/device_selection_and_fallback_for_graphics_rendering/[20:10:01] <dyl> Interesting[20:10:24] <dyl> Apparently the approach to quickly switching is to basically preallocate devices and resources thereof for all GPUs.[20:10:52] <dyl> Or if you don’t care about the hiccup between, not doing that and just copying buffer contents and some assets over[20:11:07] <dyl> It seems to me that having some kind of way to quickly move data *between* GPUs would be nice.[20:12:21] <dyl> ector: right now I’m just submitting the same command buffer every frame :p[20:12:31] <dyl> That kind of strategy is still a bit off.[20:14:08] <dyl> ector one thing I did notice and want to ask about[20:14:35] <dyl> The tutorial is using simultaneous usage as it is submitting the same buffer for all in-flight frames, yes?[20:14:52] <ector> yeah, you're not getting much parallelism between cpu and gpu that way. it's pretty easy to do a single-fence-per-frame strategy though that gets good performance. should probably write something up about it at some point..[20:14:59] <dyl> In a more real world use case I would want to record buffers per frame and use single use?[20:14:59] <ector> hm, I don[20:15:11] <ector> hm, I don't even know which tutorial you're looking at :)[20:15:35] <chrisf> dyl: you may well want to get rid of simultaneous, yes[20:15:35] <dyl> The strategy here is one fence per frame.[20:16:08] <dyl> (Interestingly by default Metal uses counting semaphores for triple-buffering and fences are hidden from you.)[20:16:12] <chrisf> dyl: it ties the driver's hands wrt patching the command buffer in-place etc.[20:16:14] <dyl> (And buffers are always single use.)[20:16:35] <ector> my strategy (and it's a common one) is to have two or three fences, each protecting that frame's resources, and round-robin between them[20:16:57] <dyl> I have three fences (for three in flight frames), and just rotate between them, yeah.[20:17:02] <ector> I use the single-use flag on all my cmdbuf usage[20:17:09] <dyl> I’m puzzling over how to combine buffer recording with synchronization.[20:17:36] <ector> you'll just have one command pool for each one of your fences. not gonna need any more sync than that[20:17:38] <ratchet_freak> check fence once you start reusing the resources you used in the buffer[20:17:57] <dyl> Should I have a separate command pool per frame/fence?[20:18:02] <ector> wait for the fence for that frame before you do anything with the resources, then you just record the cmdbufs and queue them up[20:18:05] <ector> yes[20:18:22] <chrisf> ehhh... maybe.[20:18:42] <dyl> What would the advantage of 3 pools with 1 buffer each be over 1 pool with 3 buffers?[20:18:55] <dyl> (I think I’m finally starting to get the conceptual big picture here at least.)[20:19:29] <chrisf> dyl: advantage is you can bulk-reset all the command buffers for the frame[20:19:30] <ratchet_freak> you can reset a pool and in the backend the memory management gets simpler[20:19:44] <dyl> Ahh.[20:20:45] <dyl> So 3 with 1 buffer each vs 1 pool with 3 buffers each isn't too different.[20:20:51] <dyl> But if you're submitting multiple buffers per frame...[20:21:17] *** Hadriscus <Hadriscus!Hadriscus@2a01:e35:2ebe:12f0:c167:e879:95e8:132e> has quit IRC (Quit: Leaving)[20:21:50] <chrisf> dyl: if it allows you to turn off individual command buffer freeing on the pool, the driver's job gets simpler again[20:22:53] * dyl goes to read spec on commandpool flags.[20:23:31] <dyl> Looks like by default VK_COMMAND_POOL_CREATE_RESET_COMMAND_BUFFER_BIT is NOT on.[20:24:38] <dyl> A bit confused by VK_COMMAND_POOL_RESET_RELEASE_RESOURCES_BIT.[20:25:01] <dyl> Ah I see, resetting doesn't imply releasing by default.[20:25:44] <chrisf> dyl: command buffers are ultimately backed by memory. if you're churning buffers it makes sense for the pool to hold on to the memory[20:25:49] <dyl> So, if I'm resetting a pool every frame and re-recording frames,[20:25:58] <dyl> then I *do* want the TRANSIENT_BIT on yes?[20:26:15] <dyl> (resetting but not releasing)[20:26:44] <chrisf> yes, probably[20:28:45] <dyl> One thing that's a bit annoying, std::vector<UniqueHandle<...>> does not play nicely :\.[20:29:13] <dyl> I don't use exceptions so the pattern of std::tie(Result, this->SomeField) = take(create*Unique(...)); GUARD(Result); is pretty much everywhere.[20:29:25] <dyl> (take just handles some tuple stuff to move the second parameter)[20:29:36] <dyl> But that doesn't work with std::vector.[20:30:26] <dyl> When I tried to manually create the UniqueHandles for CommandBuffers with the proper deleter it ended up blowing up, haha.[20:32:06] <dyl> Also amusing, because of UniqueHandle not being unique_ptr, you end up with stuff like...[20:32:08] <dyl> &*CommandBuffers[ImageIndex][20:32:15] <dyl> &* amuses me greatly.[20:33:05] <ratchet_freak> you could add a implicit conversion[20:33:11] <dyl> Hm, I was trying something...[20:33:14] <dyl> std::vector<vk::UniqueCommandBuffer> CommandBuffers just doesn't work at all :\.[20:33:55] <dyl> About a dozen layers of libc++ STL deep, error: call to deleted constructor of 'vk::UniqueHandle<vk::CommandBuffer>[20:34:11] <dyl> You just can't do this:[20:34:12] <dyl> auto [Result, Buffers] = Device->allocateCommandBuffersUnique(AllocInfo);[20:34:38] <dyl> The issue appears to be in how the vk::ResultValue is created.[20:38:35] *** nsf <nsf!~nsf@jiss.convex.ru> has joined ##vulkan[20:39:41] *** watered_ <watered_!~dagger@gateway/tor-sasl/watered> has joined ##vulkan[20:39:41] *** watered <watered!~dagger@gateway/tor-sasl/watered> has quit IRC (Ping timeout: 250 seconds)[20:43:55] <dyl> Should I report this as a bug on vulkan.hpp or such?[20:44:21] <dyl> (The workaround is to manually create the UniqueCommandBuffers, and push_back them onto a vector with reserved capacity, rather than resizing)[20:44:44] <dyl> (Basically, inline the contents of allocateCommandBuffersUnique.[20:45:44] <ratchet_freak> you mean the move constructor is deleted?[20:48:54] <dyl> Yes, I have the error gisted somewhere.[20:49:10] <dyl> I don't think it's a "bug" so much as the formula used everywhere else doesn't work there.[20:49:23] <dyl> https://gist.github.com/DylanLukes/52e5945b4bcdb5011df85dc058c18e74[20:49:46] <dyl> Hm, I'm trying to grok the relationship between number of fences and swapchain image count :/.[20:50:22] <dyl> Namely how ImageIndex from acquireNextImageKHR works.[20:50:59] <dyl> I imagine if you were rendering stereo (which *is* something I have to worry about...) there'd be twice the images as fences no?[20:51:29] <dyl> But what if the two stereo images use different command buffers?[20:51:32] <dyl> The mind reels. :|[20:54:42] <turol> dyl: here are my per-frame resources: https://github.com/turol/smaaDemo/blob/master/renderer/VulkanRenderer.h#L784[20:54:58] <turol> and the acquire: https://github.com/turol/smaaDemo/blob/master/renderer/VulkanRenderer.cpp#L2174[20:55:24] <dyl> Neat! Thanks for the reference.[20:55:44] <turol> i'm getting a lot of mileage out of this project[20:55:47] <dyl> Why do you pass a fence rvalue?[20:55:59] <dyl> device.acquireNextImageKHR(swapchain, UINT64_MAX, acquireSem, vk::Fence());[20:56:03] <dyl> Why not just nullptr?[20:56:10] <turol> it's vulkan.hpp[20:56:12] <turol> it's typed[20:56:26] <turol> the fence is empty, it synchronizes using the semaphore[20:56:53] <dyl> Yes, but you can just pass nullptr for vk::Fence too.[20:57:19] <turol> it might have failed at some point[20:57:27] <turol> i started this quite a while back[20:57:32] <dyl> The implicit conversion Fence( std::nullptr_t ) exists, which populates the Fence with VK_NULL_HANDLE.[20:57:43] <dyl> There are a bunch of convenient conversions for nullptr :p.[20:57:54] <dyl> Anyhow, thanks a lot![20:58:02] <dyl> Bundling up per-frame resources seems like a smart move in the future.[20:59:25] <fazias> lel[20:59:34] <fazias> I find that I have code like this[20:59:37] <fazias> result.operator VkPipeline()[20:59:44] <fazias> funny with the vulkan.hpp[21:00:46] <fazias> also I just have a pool of objects to where I free used fences and pick up new ones, and create new fence's if I run out of them. (basically never destroy, but it finds it's optimal size eventually)[21:01:03] <dyl> Why destroy fences?[21:01:10] <fazias> I don't[21:01:11] <dyl> Also, turol, I have been abusing the heck out of these macros :p.[21:01:12] <dyl> https://gist.github.com/DylanLukes/c6960d786e319b91b9c848445b05d10e[21:01:16] <fazias> I return them to the pool[21:02:16] <fazias> I do the same with commandbuffers, so in my code I can just "create" and once gpu is done with it, it returns to the pool.[21:02:29] <turol> fazias do you have a debug #ifdef which you can toggle to actually free them always?[21:02:52] <fazias> No, I don't free them ever. Never crossed my mind to do that :p[21:02:59] <turol> because i have some bad experiences with pooling where things were not being correctly freed[21:03:13] <turol> as in use-after-free when the pool thought it was free for reuse[21:03:16] <turol> a pain to debug[21:03:23] <fazias> there was one layer which caused memory leaks[21:03:26] <dyl> Well that's annoying :/.[21:03:27] <fazias> unique objects[21:03:33] <turol> having an easy way to disable the pool is a good way to debug[21:03:35] <fazias> not sure if it's a problem anymore[21:03:42] <fazias> But I don't have leaks[21:03:43] <dyl> For some reason MoltenVK isn't giving me mailbox present mode as an option... only immediate.[21:03:45] <turol> crash is so much nicer than random wonkiness[21:03:56] <dyl> So much for only fifo being guaranteed to be available (it isn't).[21:04:11] <turol> well the vulkan spec is talking about a conformant implementation[21:04:18] <turol> which moltenvk isn't (yet)[21:04:24] <dyl> "Only the VK_PRESENT_MODE_FIFO_KHR mode is guaranteed to be available"[21:04:28] <dyl> "Unfortunately some drivers currently don't properly support VK_PRESENT_MODE_FIFO_KHR"[21:04:35] <dyl> Talk about mixed signals.[21:07:28] <dyl> Well this is bizarre.[21:07:37] <dyl> I checked the MVK source... and ...[21:07:41] <dyl> it has FIFO?[21:08:27] <dyl> It looks like it's supposed to have VK_PRESENT_MODE_FIFO_KHR and *optionally* immediate presentation.[21:09:15] <dyl> Ah.[21:09:17] <dyl> "Unfortunately some drivers currently don't properly support VK_PRESENT_MODE_FIFO_KHR, so we should prefer VK_PRESENT_MODE_IMMEDIATE_KHR if VK_PRESENT_MODE_MAILBOX_KHR is not available."[21:09:21] <dyl> Is this still the case?[21:12:06] <ector> don't know any drivers that don't support FIFO[21:15:13] *** mauz555 <mauz555!~mauz555@cpe-142-129-115-205.socal.res.rr.com> has quit IRC (Read error: Connection reset by peer)[21:15:41] *** mauz555 <mauz555!~mauz555@cpe-142-129-115-205.socal.res.rr.com> has joined ##vulkan[21:18:37] <dyl> So this is interesting.[21:18:55] <dyl> I was trying to figure out why I was only getting 2 drawables in capabilities.[21:18:56] <dyl> ""Metal supports 3 concurrent drawables, but if the swapchain is destroyed and rebuilt as part of resizing, one will be held by the current display image.""[21:19:02] <dyl> (from the MoltenVK source)[21:19:11] *** mauz555 <mauz555!~mauz555@cpe-142-129-115-205.socal.res.rr.com> has quit IRC (Remote host closed the connection)[21:19:38] *** mauz555 <mauz555!~mauz555@cpe-142-129-115-205.socal.res.rr.com> has joined ##vulkan[21:20:06] <dyl> I'm not sure I understand what's going on there?[21:24:21] *** mauz555 <mauz555!~mauz555@cpe-142-129-115-205.socal.res.rr.com> has quit IRC (Ping timeout: 264 seconds)[21:26:59] *** mauz555 <mauz555!~mauz555@cpe-142-129-115-205.socal.res.rr.com> has joined ##vulkan[21:35:49] *** watered <watered!~dagger@gateway/tor-sasl/watered> has joined ##vulkan[21:38:37] *** watered_ <watered_!~dagger@gateway/tor-sasl/watered> has quit IRC (Ping timeout: 250 seconds)[21:40:47] *** watered <watered!~dagger@gateway/tor-sasl/watered> has quit IRC (Ping timeout: 250 seconds)[21:41:50] *** watered <watered!~dagger@gateway/tor-sasl/watered> has joined ##vulkan[21:44:07] *** bridger <bridger!~dagger@gateway/tor-sasl/watered> has joined ##vulkan[21:46:25] *** watered <watered!~dagger@gateway/tor-sasl/watered> has quit IRC (Ping timeout: 250 seconds)[21:46:30] *** sla_ro|master <sla_ro|master!~sla.ro@78.96.209.89> has quit IRC ()[21:47:33] *** watered <watered!~dagger@gateway/tor-sasl/watered> has joined ##vulkan[21:49:01] *** bridger <bridger!~dagger@gateway/tor-sasl/watered> has quit IRC (Ping timeout: 250 seconds)[21:51:46] *** bridger <bridger!~dagger@gateway/tor-sasl/watered> has joined ##vulkan[21:52:29] *** watered <watered!~dagger@gateway/tor-sasl/watered> has quit IRC (Ping timeout: 250 seconds)[21:53:51] *** watered <watered!~dagger@gateway/tor-sasl/watered> has joined ##vulkan[21:56:23] *** bridger <bridger!~dagger@gateway/tor-sasl/watered> has quit IRC (Ping timeout: 250 seconds)[22:07:07] *** bridger <bridger!~dagger@gateway/tor-sasl/watered> has joined ##vulkan[22:09:23] *** watered <watered!~dagger@gateway/tor-sasl/watered> has quit IRC (Ping timeout: 250 seconds)[22:10:42] *** HZun <HZun!~HZun@0x3ec72d49.osd.customer.dk.telia.net> has joined ##vulkan[22:11:59] *** bridger <bridger!~dagger@gateway/tor-sasl/watered> has quit IRC (Ping timeout: 250 seconds)[22:12:02] *** davr0s <davr0s!~textual@host86-157-70-142.range86-157.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[22:13:08] <HZun> Is there anything preventing Vulkan from being implemented for older GPUs such as Fermi or Sandy Bridge iGPU?[22:13:40] *** salamanderrake_ <salamanderrake_!~quassel@cpe-24-165-202-54.neo.res.rr.com> has joined ##vulkan[22:14:04] <dyl> Strange... I don't seem to be getting VK_ERROR_OUT_OF_DATE_KHR or VK_SUBOPTIMAL_KHR at all o.0?[22:15:14] *** bridger <bridger!~dagger@gateway/tor-sasl/watered> has joined ##vulkan[22:16:05] <turol> dyl: try resizing the window or something[22:16:12] <dyl> I am![22:16:12] <turol> fullscreen transition can also do it[22:16:21] <dyl> I also tried ppi change, and fullscreen.[22:16:27] <turol> not all implementations give those[22:16:36] <dyl> It's bizarre, nothing but eSuccess from presentKHR and acquireNextImageKHR[22:16:41] *** salamanderrake <salamanderrake!~quassel@cpe-24-165-202-54.neo.res.rr.com> has quit IRC (Ping timeout: 265 seconds)[22:18:59] *** watered <watered!~dagger@gateway/tor-sasl/watered> has joined ##vulkan[22:19:52] *** cheakoirccloud <cheakoirccloud!uid293319@gateway/web/irccloud.com/x-dtlddzzngyrrhahu> has joined ##vulkan[22:21:22] *** borkr <borkr!~borkr@static130-244.mimer.net> has quit IRC (Remote host closed the connection)[22:21:31] *** bridger <bridger!~dagger@gateway/tor-sasl/watered> has quit IRC (Ping timeout: 250 seconds)[22:22:03] *** watered_ <watered_!~dagger@gateway/tor-sasl/watered> has joined ##vulkan[22:22:10] <dyl> :/[22:22:15] <dyl> Well this is... strange.[22:23:29] *** mauz555 <mauz555!~mauz555@cpe-142-129-115-205.socal.res.rr.com> has quit IRC (Remote host closed the connection)[22:23:41] *** watered <watered!~dagger@gateway/tor-sasl/watered> has quit IRC (Ping timeout: 250 seconds)[22:24:05] *** mauz555 <mauz555!~mauz555@cpe-142-129-115-205.socal.res.rr.com> has joined ##vulkan[22:24:52] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has quit IRC (Quit: Leaving)[22:25:27] *** watered <watered!~dagger@gateway/tor-sasl/watered> has joined ##vulkan[22:26:43] *** watered_ <watered_!~dagger@gateway/tor-sasl/watered> has quit IRC (Ping timeout: 250 seconds)[22:28:25] <cheakoirccloud> They called it Vulkan, are they trying to suggest it's mythical? What about trademark infringement... is that what you find strange dyl ?[22:28:38] <dyl> No.[22:28:58] <dyl> MoltenVK *never* returns suboptimalKHR or outOfDateKHR.[22:29:11] *** mauz555 <mauz555!~mauz555@cpe-142-129-115-205.socal.res.rr.com> has quit IRC (Ping timeout: 276 seconds)[22:29:16] <dyl> I poked through the source, the relevant calls will seeminglyu never not return success.[22:29:34] <dyl> Oh wait hmmm.[22:29:41] *** bridger <bridger!~dagger@gateway/tor-sasl/watered> has joined ##vulkan[22:29:41] <dyl> return getHasSurfaceSizeChanged() ? VK_SUBOPTIMAL_KHR : VK_SUCCESS;[22:30:55] <cheakoirccloud> s/mythical/fictional/[22:31:19] <dyl> So from the looks of it,[22:31:25] <dyl> getHasSurfaceSizeChanged is never returning true.[22:31:29] *** watered <watered!~dagger@gateway/tor-sasl/watered> has quit IRC (Ping timeout: 250 seconds)[22:31:35] <dyl> Which is probably due to some interaction with GLFW...[22:31:56] *** davr0s <davr0s!~textual@host86-157-70-142.range86-157.btcentralplus.com> has joined ##vulkan[22:32:19] <dyl> It seems like GLFW isn't actually resizing the metal layer used...?[22:34:02] *** watered <watered!~dagger@gateway/tor-sasl/watered> has joined ##vulkan[22:34:31] *** bridger <bridger!~dagger@gateway/tor-sasl/watered> has quit IRC (Ping timeout: 250 seconds)[22:35:32] <dyl> What this seems to suggest is that using GLFW, your drawable size is whatever you initialize the window sad.[22:35:34] <dyl> as*[22:35:38] <dyl> No updates possible.[22:38:25] *** watered <watered!~dagger@gateway/tor-sasl/watered> has quit IRC (Ping timeout: 250 seconds)[22:44:31] <HZun> Let me change my question: Do any of you guys know why Vulkan decided on requireing compute capabilities as opposed to creating a low-level API that would also support older GPUs? and do you think that the Vulkan and OpenCL merge will open Vulkan up to being support on older GPUs as well (because of their focus on "optionality")?[22:44:40] *** watered <watered!~dagger@gateway/tor-sasl/watered> has joined ##vulkan[22:45:23] <ratchet_freak> because they need to set a baseline[22:45:47] <ratchet_freak> and as is a generation of vulkan capable gpus are not getting vulkan capable drivers[22:45:59] <ratchet_freak> NVidea's Fermi architecture IIRC[22:47:09] <ratchet_freak> it takes time and money to write those drivers and if there are not enough people using the cards then it is literally not worth the investment to create the driver[22:47:32] *** bridger <bridger!~dagger@gateway/tor-sasl/watered> has joined ##vulkan[22:47:33] <turol> nvidia originally said fermi would be supported[22:47:37] <turol> but then recanted[22:47:49] <turol> i was pretty miffed since i have a laptop with fermi[22:48:56] *** nsf <nsf!~nsf@jiss.convex.ru> has quit IRC (Quit: WeeChat 2.1)[22:49:13] *** mauz555 <mauz555!~mauz555@cpe-142-129-115-205.socal.res.rr.com> has joined ##vulkan[22:49:23] *** watered_ <watered_!~dagger@gateway/tor-sasl/watered> has joined ##vulkan[22:49:27] *** mauz555 <mauz555!~mauz555@cpe-142-129-115-205.socal.res.rr.com> has quit IRC (Remote host closed the connection)[22:49:41] *** watered <watered!~dagger@gateway/tor-sasl/watered> has quit IRC (Ping timeout: 250 seconds)[22:52:17] *** bridger <bridger!~dagger@gateway/tor-sasl/watered> has quit IRC (Ping timeout: 250 seconds)[22:53:26] <HZun> ok thanks. that makes sense :)[22:54:01] *** watered_ <watered_!~dagger@gateway/tor-sasl/watered> has quit IRC (Ping timeout: 250 seconds)[22:54:52] *** watered <watered!~dagger@gateway/tor-sasl/watered> has joined ##vulkan[22:57:57] *** bridger <bridger!~dagger@gateway/tor-sasl/watered> has joined ##vulkan[23:00:05] *** watered <watered!~dagger@gateway/tor-sasl/watered> has quit IRC (Ping timeout: 250 seconds)[23:00:16] *** Guest4630 <Guest4630!4d3b9548@gateway/web/cgi-irc/kiwiirc.com/ip.77.59.149.72> has joined ##vulkan[23:02:05] *** mauz555 <mauz555!~mauz555@cpe-142-129-115-205.socal.res.rr.com> has joined ##vulkan[23:05:17] *** watered <watered!~dagger@gateway/tor-sasl/watered> has joined ##vulkan[23:07:01] *** bridger <bridger!~dagger@gateway/tor-sasl/watered> has quit IRC (Ping timeout: 250 seconds)[23:09:47] <dyl> wtf is going on with glfw o.0[23:10:03] <dyl> I get window and framebuffer resize events.[23:12:39] *** watered <watered!~dagger@gateway/tor-sasl/watered> has quit IRC (Ping timeout: 250 seconds)[23:13:02] <lpg> those two are not necessarily correlated 1:1[23:13:10] <dyl> Oh, no, they're not, they're 2:1, and that's fine.[23:13:21] <dyl> The problem is that this is never happening: https://github.com/KhronosGroup/MoltenVK/blob/bbe5370f62cb96be618e34a8dc57e003c045683c/MoltenVK/MoltenVK/GPUObjects/MVKSwapchain.mm#L82[23:13:22] *** mauz555 <mauz555!~mauz555@cpe-142-129-115-205.socal.res.rr.com> has quit IRC (Remote host closed the connection)[23:13:33] <dyl> The resize is not translating to a resize of the drawable.[23:13:50] *** mauz555 <mauz555!~mauz555@cpe-142-129-115-205.socal.res.rr.com> has joined ##vulkan[23:13:58] *** bridger <bridger!~dagger@gateway/tor-sasl/watered> has joined ##vulkan[23:14:31] *** mauz555 <mauz555!~mauz555@cpe-142-129-115-205.socal.res.rr.com> has quit IRC (Read error: Connection reset by peer)[23:14:39] *** mauz555 <mauz555!~mauz555@cpe-142-129-115-205.socal.res.rr.com> has joined ##vulkan[23:16:27] <dyl> There's some kind of disconnect between GLFWContentView and the MTLView.[23:17:04] *** ville_ <ville_!~ville@87-93-69-243.bb.dnainternet.fi> has joined ##vulkan[23:17:33] *** mauz555 <mauz555!~mauz555@cpe-142-129-115-205.socal.res.rr.com> has quit IRC (Remote host closed the connection)[23:18:57] *** ville <ville!~ville@37-136-113-215.rev.dnainternet.fi> has quit IRC (Ping timeout: 248 seconds)[23:18:58] *** ville_ is now known as ville[23:19:09] *** bridger <bridger!~dagger@gateway/tor-sasl/watered> has quit IRC (Ping timeout: 250 seconds)[23:22:57] *** bridger <bridger!~dagger@gateway/tor-sasl/watered> has joined ##vulkan[23:26:24] *** watered <watered!~dagger@gateway/tor-sasl/watered> has joined ##vulkan[23:29:07] *** bridger <bridger!~dagger@gateway/tor-sasl/watered> has quit IRC (Ping timeout: 250 seconds)[23:29:23] *** watered_ <watered_!~dagger@gateway/tor-sasl/watered> has joined ##vulkan[23:30:19] *** Deluxe <Deluxe!~Deluxe@212.4.150.151> has quit IRC (Read error: Connection reset by peer)[23:31:17] *** watered <watered!~dagger@gateway/tor-sasl/watered> has quit IRC (Ping timeout: 250 seconds)[23:31:30] *** bridger <bridger!~dagger@gateway/tor-sasl/watered> has joined ##vulkan[23:34:24] *** watered__ <watered__!~dagger@gateway/tor-sasl/watered> has joined ##vulkan[23:34:45] *** watered_ <watered_!~dagger@gateway/tor-sasl/watered> has quit IRC (Ping timeout: 250 seconds)[23:35:06] *** watered__ <watered__!~dagger@gateway/tor-sasl/watered> has quit IRC (Remote host closed the connection)[23:36:03] *** bridger <bridger!~dagger@gateway/tor-sasl/watered> has quit IRC (Ping timeout: 250 seconds)[23:40:39] *** HZun <HZun!~HZun@0x3ec72d49.osd.customer.dk.telia.net> has quit IRC (Quit: Leaving)[23:45:56] <dyl> The heck.[23:46:37] <dyl> VULKAN_HPP_ASSERT is still assert in CLion but I don't get hard crashes for every single createResultValue, but when I cmake for xcode (for looking at view hierarchy), I do :\[23:48:49] <dyl> Uh, ok.[23:49:04] <dyl> Apparently GLFW doesn't require any extensions when I'm running from inside Xcode?[23:49:08] <dyl> That makes literally zero sense.[23:49:17] <dyl> (not even mvk_macos_surface)[23:52:22] <dyl> The result of glfwGetRequiredInstanceExtensions is actually different depending on whether I'm running under LLDB in CLion or in XCode.[23:52:24] <dyl> What the actual heck.[23:53:22] <dyl> Running what Xcode *builds* manually works just fine though :|.[23:58:44] <dyl> Could it be an issue with xcode doing some kind of sandboxing that's blocking loading?