February 27, 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 | >
February 27, 2018 [00:00:51] *** skl_ <skl_!~skl___@dyn-pppoe-142-51-206-163.vianet.ca> has joined ##vulkan[00:04:13] *** skl <skl!~skl___@dyn-pppoe-142-51-203-84.vianet.ca> has quit IRC (Ping timeout: 240 seconds)[00:05:29] *** BearishMushroom <BearishMushroom!~BearishMu@82-209-154-59.cust.bredband2.com> has quit IRC (Read error: Connection reset by peer)[00:15:29] *** threenuc <threenuc!~threenuc@88.156.163.16> has quit IRC (Ping timeout: 252 seconds)[00:25:40] *** davr0s <davr0s!~textual@host86-147-196-30.range86-147.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[00:28:11] *** davr0s <davr0s!~textual@host86-147-196-30.range86-147.btcentralplus.com> has joined ##vulkan[00:50:14] *** MrFlibble <MrFlibble!MrFlibble@2.220.67.202> has joined ##vulkan[01:17:28] *** random_james is now known as random_james_awy[01:22:39] *** panda81 <panda81!a2f6d81c@gateway/web/cgi-irc/kiwiirc.com/ip.162.246.216.28> has joined ##vulkan[01:28:00] *** derhass <derhass!~derhass@dslb-094-222-155-209.094.222.pools.vodafone-ip.de> has quit IRC (Quit: leaving)[01:30:28] *** skl_ <skl_!~skl___@dyn-pppoe-142-51-206-163.vianet.ca> has quit IRC (Read error: Connection reset by peer)[01:39:47] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-82s3g7mzgy0p2f49u7u.18120a2.ip6.access.telenet.be> has quit IRC (Ping timeout: 245 seconds)[02:01:27] *** davr0s <davr0s!~textual@host86-147-196-30.range86-147.btcentralplus.com> has quit IRC (Ping timeout: 252 seconds)[02:11:32] *** cheako <cheako!~cheako@2601:440:4100:4d1f::834> has joined ##vulkan[02:25:19] *** MrFlibble <MrFlibble!MrFlibble@2.220.67.202> has left ##vulkan[02:34:53] *** jdashg <jdashg!~jdashg@corp-nat.fw1.untrust.mtv2.mozilla.net> has quit IRC (Ping timeout: 240 seconds)[02:38:31] *** cheako <cheako!~cheako@2601:440:4100:4d1f::834> has quit IRC (Ping timeout: 245 seconds)[02:40:30] *** cheako <cheako!~cheako@2601:440:4100:4d1f::834> has joined ##vulkan[02:47:34] *** glima <glima!glima@enlightenment/developer/glima> has quit IRC (Remote host closed the connection)[02:55:05] *** ciaala <ciaala!~crypt@182.192.6.85.dynamic.wline.res.cust.swisscom.ch> has quit IRC (Quit: Konversation terminated!)[03:03:25] *** marijnfs <marijnfs!~smuxi@2a01:c22:7a24:b600:4868:f2ab:8be9:7b8c> has quit IRC (Ping timeout: 252 seconds)[03:08:15] *** marijnfs <marijnfs!~smuxi@2a01:c22:7609:4400:248d:6c69:b494:16a5> has joined ##vulkan[03:16:27] *** cheako <cheako!~cheako@2601:440:4100:4d1f::834> has quit IRC (Ping timeout: 245 seconds)[03:28:20] *** duckwho <duckwho!~duckwho@dhcp158-157.calvin.edu> has joined ##vulkan[03:28:47] *** duckwho <duckwho!~duckwho@dhcp158-157.calvin.edu> has quit IRC (Client Quit)[03:48:21] *** jdashg <jdashg!~jdashg@c-73-71-138-56.hsd1.ca.comcast.net> has joined ##vulkan[03:50:42] *** duckwho <duckwho!~duckwho@159.89.86.180> has joined ##vulkan[03:57:57] *** Kingsquee <Kingsquee!~kingsquee@d108-180-237-219.bchsia.telus.net> has joined ##vulkan[04:30:56] *** slime <slime!~slime73@24.215.81.93> has quit IRC (Quit: This computer has gone to sleep)[04:59:48] <Bl4ckb0ne> is it normal that glfw is not loading the VK_KHR_xlib_surface by default on X11?[05:16:37] *** sla_ro|master <sla_ro|master!~sla.ro@78.96.209.89> has joined ##vulkan[05:19:11] *** cheako <cheako!~cheako@2601:440:4100:4d1f::834> has joined ##vulkan[06:03:34] *** sla_ro|master <sla_ro|master!~sla.ro@78.96.209.89> has quit IRC ()[06:05:20] *** glYoda <glYoda!~MTLYoda@c-73-25-27-206.hsd1.or.comcast.net> has quit IRC (Quit: glYoda)[06:08:00] *** glYoda <glYoda!~MTLYoda@c-73-25-27-206.hsd1.or.comcast.net> has joined ##vulkan[06:36:52] *** cheako <cheako!~cheako@2601:440:4100:4d1f::834> has quit IRC (Ping timeout: 245 seconds)[06:38:13] *** jdashg <jdashg!~jdashg@c-73-71-138-56.hsd1.ca.comcast.net> has quit IRC (Ping timeout: 240 seconds)[06:39:22] *** cheako <cheako!~cheako@2601:440:4100:4d1f::834> has joined ##vulkan[07:01:31] *** hgoel <hgoel!uid175521@gateway/web/irccloud.com/x-mptlhmkrkifhqwym> has joined ##vulkan[07:08:39] *** nsf <nsf!~nsf@jiss.convex.ru> has joined ##vulkan[07:18:48] <cheako> I made a game in vulkan, you stare at a wall and walk around. https://github.com/cheako/cheako-vulkan/tree/2b95de9594a5917b714180827b405a9f220d7590[07:24:08] <Ralith> sounds pretty intense[07:26:38] <cheako> I'm just happy I figured out mvp matrix.[07:27:29] <cheako> Now I have to tackle vector normals.[07:28:21] <cheako> ...or should I do a texture first?[07:34:45] <cheako> Next is likely a vertex index buffer.[07:39:21] *** cheako <cheako!~cheako@2601:440:4100:4d1f::834> has quit IRC (Ping timeout: 245 seconds)[07:48:20] <duckwho> exit[07:49:34] *** Deluxe <Deluxe!~Deluxe@2001:67c:1220:80e:e9:1d2:f14f:e47f> has joined ##vulkan[07:52:59] *** cheako <cheako!~cheako@2601:440:4100:4d1f::834> has joined ##vulkan[07:54:02] *** jdashg <jdashg!~jdashg@c-73-71-138-56.hsd1.ca.comcast.net> has joined ##vulkan[07:58:06] *** cheako <cheako!~cheako@2601:440:4100:4d1f::834> has quit IRC (Ping timeout: 245 seconds)[08:00:30] *** tambre <tambre!~tambre@da40-d8dc-0637-59f5-ab80-8a0a-07d0-2001.dyn.estpak.ee> has joined ##vulkan[08:05:26] *** Fats <Fats!fats@gateway/vpn/privateinternetaccess/fats> has quit IRC (Remote host closed the connection)[08:06:39] *** Fats <Fats!fats@gateway/vpn/privateinternetaccess/fats> has joined ##vulkan[08:15:38] *** xissburg <xissburg!~xissburg@unaffiliated/xissburg> has quit IRC (Quit: ZZZzzz…)[09:08:45] *** davr0s <davr0s!~textual@host86-147-196-30.range86-147.btcentralplus.com> has joined ##vulkan[09:23:34] *** Ralith__ <Ralith__!~ralith@172.92.102.204> has joined ##vulkan[09:26:27] *** Ralith_ <Ralith_!~ralith@c-24-56-225-47.customer.broadstripe.net> has quit IRC (Ping timeout: 240 seconds)[10:00:58] *** hampusw <hampusw!~Hampus@37.139.156.40> has joined ##vulkan[10:07:28] *** ratchetfreak <ratchetfreak!c351a8d8@gateway/web/freenode/ip.195.81.168.216> has joined ##vulkan[10:42:30] *** MrCooper <MrCooper!~MrCooper@230.154.195.178.dynamic.wline.res.cust.swisscom.ch> has quit IRC (Remote host closed the connection)[10:48:02] *** Sairon <Sairon!~Sairon@185.57.104.138> has joined ##vulkan[10:50:48] *** stamina <stamina!~stamina@144-156-045-062.dynamic.caiway.nl> has joined ##vulkan[11:00:53] *** jdashg <jdashg!~jdashg@c-73-71-138-56.hsd1.ca.comcast.net> has quit IRC (Ping timeout: 240 seconds)[11:03:14] *** ratchetfreak <ratchetfreak!c351a8d8@gateway/web/freenode/ip.195.81.168.216> has quit IRC (Ping timeout: 260 seconds)[11:09:34] *** MrCooper <MrCooper!~MrCooper@2a02:120b:2c39:ae60:3a63:bbff:feca:3701> has joined ##vulkan[11:09:39] *** }P{ <}P{!~andrei@82-132-230-77.dab.02.net> has joined ##vulkan[11:11:07] *** }P{ <}P{!~andrei@82-132-230-77.dab.02.net> has left ##vulkan ("brb,")[11:11:27] *** MrCooper <MrCooper!~MrCooper@2a02:120b:2c39:ae60:3a63:bbff:feca:3701> has quit IRC (Remote host closed the connection)[11:11:40] *** MrCooper <MrCooper!~MrCooper@2a02:120b:2c39:ae60:2510:a606:cd62:8449> has joined ##vulkan[11:54:20] *** Kingsquee <Kingsquee!~kingsquee@d108-180-237-219.bchsia.telus.net> has quit IRC (Quit: Just Monica.)[12:28:11] *** tambre <tambre!~tambre@da40-d8dc-0637-59f5-ab80-8a0a-07d0-2001.dyn.estpak.ee> has quit IRC (Read error: Connection reset by peer)[12:29:04] *** halbeno_ <halbeno_!~halbeno@node-1w7jra22dpc6yrvo9wam83mu0.ipv6.telus.net> has quit IRC (Remote host closed the connection)[12:29:31] *** halbeno_ <halbeno_!~halbeno@node-1w7jra22dpc6yrvo9wam83mu0.ipv6.telus.net> has joined ##vulkan[12:29:49] *** neure <neure!~tsuoranta@62.209.167.43> has joined ##vulkan[12:33:32] *** mij <mij!~mijowh@75.97.242.215.res-cmts.leh.ptd.net> has joined ##vulkan[12:36:01] *** mijo <mijo!~mijowh@75.97.242.215.res-cmts.leh.ptd.net> has quit IRC (Ping timeout: 248 seconds)[12:46:01] *** tambre <tambre!~tambre@da40-d8dc-0637-59f5-ab80-8a0a-07d0-2001.dyn.estpak.ee> has joined ##vulkan[13:03:54] *** slime <slime!~slime73@blk-215-81-93.eastlink.ca> has joined ##vulkan[13:05:58] *** mijo <mijo!~mijowh@75.97.242.215.res-cmts.leh.ptd.net> has joined ##vulkan[13:09:20] *** mij <mij!~mijowh@75.97.242.215.res-cmts.leh.ptd.net> has quit IRC (Ping timeout: 276 seconds)[13:18:26] *** slime <slime!~slime73@blk-215-81-93.eastlink.ca> has quit IRC (Quit: This computer has gone to sleep)[13:29:33] <exDM69_> https://www.khronos.org/news/press/vulkan-applications-enabled-on-apple-platforms[13:29:38] <exDM69_> https://www.anandtech.com/show/12465/khronos-group-extends-vulkan-portability-with-opensource[13:29:47] <exDM69_> moltenvk is now open source[13:38:32] *** ratchetfreak <ratchetfreak!c351a8d8@gateway/web/freenode/ip.195.81.168.216> has joined ##vulkan[13:39:32] *** sla_ro|master <sla_ro|master!~sla.ro@78.96.209.89> has joined ##vulkan[14:03:43] *** mij <mij!~mijowh@75.97.242.215.res-cmts.leh.ptd.net> has joined ##vulkan[14:05:53] *** mijo <mijo!~mijowh@75.97.242.215.res-cmts.leh.ptd.net> has quit IRC (Ping timeout: 276 seconds)[14:12:50] *** mij <mij!~mijowh@75.97.242.215.res-cmts.leh.ptd.net> has quit IRC (Quit: Leaving)[14:41:22] *** stamina <stamina!~stamina@144-156-045-062.dynamic.caiway.nl> has quit IRC (Quit: WeeChat 2.0.1)[14:47:39] *** threenuc <threenuc!~threenuc@88.156.163.16> has joined ##vulkan[15:03:21] *** Berserker66 <Berserker66!~Fabian_Di@dslb-088-065-161-171.088.065.pools.vodafone-ip.de> has joined ##vulkan[15:20:45] <hampusw> exDM69_: it's awesome. one less obstacle for adoption :)[15:22:06] *** neure <neure!~tsuoranta@62.209.167.43> has quit IRC (Quit: Leaving)[15:25:49] <exDM69_> indeed :)[15:27:00] *** davr0s <davr0s!~textual@host86-147-196-30.range86-147.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[15:28:28] *** davr0s <davr0s!~textual@host86-147-196-30.range86-147.btcentralplus.com> has joined ##vulkan[15:30:07] *** davr0s <davr0s!~textual@host86-147-196-30.range86-147.btcentralplus.com> has quit IRC (Client Quit)[15:32:28] *** davr0s <davr0s!~textual@host86-147-196-30.range86-147.btcentralplus.com> has joined ##vulkan[15:32:31] *** davr0s <davr0s!~textual@host86-147-196-30.range86-147.btcentralplus.com> has quit IRC (Client Quit)[15:38:13] *** hampusw <hampusw!~Hampus@37.139.156.40> has quit IRC (Quit: Leaving)[16:25:54] *** Borkr <Borkr!~Borkr@mail.seaonics.com> has quit IRC (Quit: Leaving)[16:25:57] *** snyp <snyp!~Snyp@103.56.236.26> has joined ##vulkan[16:27:34] *** Lucretia <Lucretia!~laguest@pdpc/supporter/active/lucretia> has quit IRC (Remote host closed the connection)[16:29:39] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has joined ##vulkan[16:29:47] *** Lucretia <Lucretia!~laguest@2a02:c7d:3c35:b000:325a:3aff:fe0f:37a5> has joined ##vulkan[16:29:47] *** Lucretia <Lucretia!~laguest@2a02:c7d:3c35:b000:325a:3aff:fe0f:37a5> has quit IRC (Changing host)[16:29:47] *** Lucretia <Lucretia!~laguest@pdpc/supporter/active/lucretia> has joined ##vulkan[16:36:10] <Dirkson> Hey all. glfw provides a function to query pointers for vulkan functions. Under what circumstances would I need to do this?[16:37:39] *** ZeroWalker <ZeroWalker!~Zerowalke@78-67-154-24-no268.tbcn.telia.com> has joined ##vulkan[16:38:06] *** Deluxe <Deluxe!~Deluxe@2001:67c:1220:80e:e9:1d2:f14f:e47f> has quit IRC (Remote host closed the connection)[16:42:25] <ratchetfreak> extension functions[16:46:35] <Dirkson> ratchetfreak: Which are any function with "KHR"? I am currently calling some of those without (apparently) needing to query for them.[16:51:33] <ratchetfreak> wsi (about the surface and swapchain) related functions don't need querying[16:52:05] *** ville <ville!~ville@176-93-104-145.bb.dnainternet.fi> has quit IRC (Ping timeout: 252 seconds)[16:52:19] <ratchetfreak> but if you query the function you are getting a faster path to the driver by a single layer because you avoid the trampoline[16:56:54] *** threenuc <threenuc!~threenuc@88.156.163.16> has quit IRC (Ping timeout: 260 seconds)[17:09:05] *** Sairon <Sairon!~Sairon@185.57.104.138> has quit IRC (Ping timeout: 240 seconds)[17:35:47] *** davr0s <davr0s!~textual@host86-157-70-106.range86-157.btcentralplus.com> has joined ##vulkan[17:56:59] <Dirkson> ratchetfreak: Is the faster path limited to the extension functions?[17:58:48] *** graphitemaster <graphitemaster!~graphitem@unaffiliated/graphitemaster> has quit IRC (Quit: ZNC - http://znc.in)[18:06:00] *** graphitemaster <graphitemaster!~graphitem@unaffiliated/graphitemaster> has joined ##vulkan[18:09:09] *** xissburg <xissburg!~xissburg@unaffiliated/xissburg> has joined ##vulkan[18:14:41] <ratchetfreak> no, all functions benefit from it[18:16:55] *** snyp <snyp!~Snyp@103.56.236.26> has quit IRC (Quit: Leaving)[18:17:21] *** Deluxe <Deluxe!~Deluxe@212.4.150.151> has joined ##vulkan[18:19:28] <Dirkson> ratchetfreak: Cool. but I assume I'm saving something like a null test, then a lookup? So I wouldn't see a performance difference unless I use the function more than once?[18:20:32] <ratchetfreak> yeah it's essentially the same cost as a virtual member function call[18:24:29] <Dirkson> ratchetfreak: Cool. I assume there's no (simple) method provided by vulkan for querying these, since glfw has gone to the trouble of handing me a way to query them?[18:25:24] *** ratchetfreak <ratchetfreak!c351a8d8@gateway/web/freenode/ip.195.81.168.216> has quit IRC (Ping timeout: 260 seconds)[18:25:36] <Dirkson> Was it something I said? o.o[18:33:25] <Dirkson> After reading some more, I did figure out the answer though - The glfw functions actually provide more than the vulkan ones, falling back to various system-specific methods of finding the correct pointer if vulkan fails to do so.[18:34:18] <chrisf> sounds dubious[18:35:24] <Dirkson> Does it? Why?[18:40:40] *** cheako <cheako!~cheako@2601:440:4100:4d1f::834> has joined ##vulkan[18:49:21] *** cheako <cheako!~cheako@2601:440:4100:4d1f::834> has quit IRC (Ping timeout: 245 seconds)[18:49:40] *** glima <glima!~glima@192.55.54.38> has joined ##vulkan[18:49:40] *** glima <glima!~glima@192.55.54.38> has quit IRC (Changing host)[18:49:40] *** glima <glima!~glima@enlightenment/developer/glima> has joined ##vulkan[18:51:41] *** cheako <cheako!~cheako@2601:440:4100:4d1f::834> has joined ##vulkan[19:02:23] *** random_james_awy is now known as random_james[19:11:08] *** Berserker66 <Berserker66!~Fabian_Di@dslb-088-065-161-171.088.065.pools.vodafone-ip.de> has left ##vulkan[19:11:25] *** davr0s <davr0s!~textual@host86-157-70-106.range86-157.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[19:19:50] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-82s3g7mzgy0p2f49u7u.18120a2.ip6.access.telenet.be> has joined ##vulkan[19:26:51] *** cheako <cheako!~cheako@2601:440:4100:4d1f::834> has quit IRC (Ping timeout: 245 seconds)[19:29:15] *** MrFlibble <MrFlibble!MrFlibble@90.203.46.192> has joined ##vulkan[19:32:04] *** ciaala <ciaala!~crypt@182.192.6.85.dynamic.wline.res.cust.swisscom.ch> has joined ##vulkan[19:34:08] *** MrCooper <MrCooper!~MrCooper@2a02:120b:2c39:ae60:2510:a606:cd62:8449> has quit IRC (Ping timeout: 256 seconds)[19:37:32] *** davr0s <davr0s!~textual@host86-157-70-106.range86-157.btcentralplus.com> has joined ##vulkan[19:43:23] *** MrCooper <MrCooper!~MrCooper@2a02:120b:2c39:ae60:3a63:bbff:feca:3701> has joined ##vulkan[19:49:08] *** ville <ville!~ville@188-67-25-39.bb.dnainternet.fi> has joined ##vulkan[19:50:48] *** MrFlibble <MrFlibble!MrFlibble@90.203.46.192> has quit IRC (Disconnected by services)[19:50:54] *** MrFlibble2 <MrFlibble2!MrFlibble@176.249.3.217> has joined ##vulkan[19:51:21] <ZeroWalker> yay, guten aben:)[19:55:09] *** gdsfgdfsgdsf <gdsfgdfsgdsf!MrFlibble2@176.251.71.19> has joined ##vulkan[19:55:11] *** MrFlibble2 <MrFlibble2!MrFlibble@176.249.3.217> has quit IRC (Ping timeout: 245 seconds)[19:55:15] *** gdsfgdfsgdsf is now known as MrFlibble[19:58:41] *** ville <ville!~ville@188-67-25-39.bb.dnainternet.fi> has quit IRC (Ping timeout: 248 seconds)[19:59:28] *** marijnfs <marijnfs!~smuxi@2a01:c22:7609:4400:248d:6c69:b494:16a5> has quit IRC (Remote host closed the connection)[20:04:44] *** snyp <snyp!~Snyp@103.56.236.91> has joined ##vulkan[20:17:49] *** BearishMushroom <BearishMushroom!~BearishMu@82-209-154-59.cust.bredband2.com> has joined ##vulkan[20:30:23] *** MrFlibble <MrFlibble!MrFlibble2@176.251.71.19> has quit IRC (Disconnected by services)[20:30:27] *** MrFlibble2 <MrFlibble2!MrFlibble@2.219.208.181> has joined ##vulkan[20:33:15] *** cheako <cheako!~cheako@2601:440:4100:4d1f::834> has joined ##vulkan[20:39:00] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-82s3g7mzgy0p2f49u7u.18120a2.ip6.access.telenet.be> has quit IRC (Read error: Connection reset by peer)[20:39:27] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-82s3g7mzgy0p2f49u7u.18120a2.ip6.access.telenet.be> has joined ##vulkan[20:44:18] <ZeroWalker> is there some cool vulkan videos that explain it (in higher level terms i guess)?[20:44:33] <ZeroWalker> something to watch without having to use my 2 brain cells on overdrive[20:45:07] <ZeroWalker> kinda like watching videos explaining stuff, wether i really use it or not, to kill time and out of interest, and hoping i might learn something[20:45:20] <ratchetfreak> what are you having trouble understanding?[20:45:34] *** joakimds_ <joakimds_!uid154127@gateway/web/irccloud.com/x-fvknxtqitwvhvspe> has quit IRC (Quit: Connection closed for inactivity)[20:46:27] *** borkr <borkr!~borkr@static130-244.mimer.net> has joined ##vulkan[20:47:02] *** Lucretia <Lucretia!~laguest@pdpc/supporter/active/lucretia> has quit IRC (Remote host closed the connection)[20:47:09] *** threenuc <threenuc!~threenuc@88.156.163.16> has joined ##vulkan[20:48:14] *** MrFlibble2 <MrFlibble2!MrFlibble@2.219.208.181> has quit IRC (Ping timeout: 276 seconds)[20:48:25] <ZeroWalker> oh, it's not a particular issue, not even using Vulkan as of now, and currently not doing any programming as i am busy with other stuff. But i like to watch things during my spare time, and as i barely know anything about vulkan, maybe there is some videos that go through a bit of things[20:48:31] <ZeroWalker> but maybe not;d[20:48:44] *** davr0s <davr0s!~textual@host86-157-70-106.range86-157.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[20:49:22] <ratchetfreak> how familiar are you with opengl (or other graphics apis)?[20:51:14] <ZeroWalker> hmm, well not sure how to define, maybe you could ask some questions?[20:51:23] <ZeroWalker> it's probably quite low[20:51:43] <ratchetfreak> you know how to use shaders, ssbo, ubo, VAO, separate vertex format?[20:52:30] *** Lucretia <Lucretia!~laguest@pdpc/supporter/active/lucretia> has joined ##vulkan[20:52:51] <ZeroWalker> i know of vertex and fragment shaders, and kinda how to use them. VAO still confuses me, but i see it as something that holds VBO stuff, or was it just vertex attributes maybe[20:52:56] <ZeroWalker> the other stuff, no clue[20:52:59] <turol> have you read (and understood) "a trip through the graphics pipeline"?[20:53:12] <ratchetfreak> https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-graphics-pipeline-2011-index/[20:53:24] <turol> yes, that[20:53:41] <turol> you _need_ to understand all of that for vulkan to make sense[20:54:09] <ZeroWalker> ah, hmm, seems like a ton of pages, is there visual stuff, or just plain text?[20:54:17] <turol> there are pictures[20:55:08] <ZeroWalker> oh that helps, hmm maybe even someone reads through it and comments on a video, would love that, will give it a check and a try[20:55:49] <Fats> Imo it's entirely possible to explain Vulkan and give a big-picture overview without going through how GPU actually implements things under the hood.[20:55:55] *** borkr <borkr!~borkr@static130-244.mimer.net> has quit IRC (Quit: Leaving)[20:56:12] <ratchetfreak> yeah but that doesn't impart how to properly use it[20:56:31] <ratchetfreak> if you know under the hood you understand why renderpasses are important[20:56:32] <Fats> he wasn't asking about how to properly use it, he wanted to just know about it[20:57:00] *** dindinx <dindinx!~dindinx@unaffiliated/dindinx> has joined ##vulkan[20:57:09] <Fats> he (or anyone else) can then move onto the details about why things are the way they are, and then go deeper, if they like[20:57:32] <Fats> I think it's important to encourage people rather than discourage with walls of text and huge books that they "must" read before they satisfy their curiousity about a new graphics api, and so on.[20:57:39] *** Kingsquee <Kingsquee!~kingsquee@d108-180-237-219.bchsia.telus.net> has joined ##vulkan[21:06:15] <ZeroWalker> oh, well, i might be on your side here Fats, mostly because i am quite a terrible reader, reading books never really help me out, so i always end up asking around or watching visual examples for the stuff[21:06:18] <ZeroWalker> but then again that's just me[21:06:58] <Fats> people learn in different ways[21:07:34] <Fats> some like to read text, others like to watch, some like audio, some focus on tutorials or code, etc.[21:07:36] <ratchetfreak> if you look around you can find presentations that explain high level how vulkan work (though mostly by highlighting what is different from opengl)[21:08:04] <ZeroWalker> well thank you;d[21:08:19] <ZeroWalker> ah, hmm, might have seen such stuff, i know i saw stuff when vulkan arrived, mostly stuff like[21:08:30] <ZeroWalker> "draw calls performance" if i remember correctly[21:08:43] <ZeroWalker> that was the big hype with DX12 and Vulkan[21:09:02] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-82s3g7mzgy0p2f49u7u.18120a2.ip6.access.telenet.be> has quit IRC (Read error: Connection reset by peer)[21:09:27] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-82s3g7mzgy0p2f49u7u.18120a2.ip6.access.telenet.be> has joined ##vulkan[21:12:23] <Fats> ZeroWalker: https://www.youtube.com/watch?v=l3Hyd2sWSvA - this is a technical overview of what Vulkan provides/fixes[21:12:39] <Fats> ZeroWalker: if you want to see code, I think there are a couple of youtube tutorials as well[21:13:17] <ZeroWalker> that might be something, will check the overview out, thanks:)[21:13:22] <ratchetfreak> one comment about tutorials: many will do a transition of swapchain images as soon as the swapchain is created[21:13:38] <ratchetfreak> this is not allowed and entirely unnecessary[21:13:55] *** tambre <tambre!~tambre@da40-d8dc-0637-59f5-ab80-8a0a-07d0-2001.dyn.estpak.ee> has quit IRC (Ping timeout: 265 seconds)[21:17:00] <ZeroWalker> no clue what that means, so clearly not there yet, listening to the overview, interesting[21:17:18] <ratchetfreak> yeah that has to do with preparing for output to screen[21:19:47] <ZeroWalker> ah yeah make sense, seen swapchain in D3D come up[21:20:01] <ZeroWalker> (it sounds like different buffers in a chain that just flip about)[21:21:33] <ratchetfreak> just about, and the render loop is acquireNextImage(), queueSubmit(), present()[21:23:08] <ratchetfreak> in queue submit you submit a command buffer that contains the drawcalls[21:25:39] <ZeroWalker> ah, so in this example, it's a basically synchronous workload, you basically ignore the "queue" part and just do "doWork" so to speak?[21:25:40] <ZeroWalker> https://youtu.be/l3Hyd2sWSvA?t=646[21:25:53] <ZeroWalker> this makes me confused, isn't it like this in OpenGL, you give it waht the gpu want[21:26:47] <ZeroWalker> wow, this i like: https://youtu.be/l3Hyd2sWSvA?t=738[21:28:11] <ratchetfreak> in opengl the actual internal format is something that is compatible with the one you request, in vulkan there are only the ones that are provided[21:28:40] <ratchetfreak> a few are guaranteed to be provided but for example none of the 3 component formats are required[21:29:21] *** cheako <cheako!~cheako@2601:440:4100:4d1f::834> has quit IRC (Ping timeout: 245 seconds)[21:30:28] <ZeroWalker> not sure i understand the difference, can you say an example?[21:30:44] <ZeroWalker> also, what does this part mean: https://youtu.be/l3Hyd2sWSvA?t=850 (headless rendering?)[21:31:18] <ZeroWalker> as for the command queue part and threading, it sounds totally awesome (not that i would know when/how to use it, but it really sounds like it unlock things)[21:32:02] <ratchetfreak> rendering without any screen attached[21:32:06] <ratchetfreak> common for servers[21:32:59] <ratchetfreak> less than you'd think building a single command buffer must still happen on a single thread[21:34:23] <ratchetfreak> about the format: for example opengl lets you specify internal format GL_RGB8 which is a 8 bit per channel 3 color format[21:34:33] <ZeroWalker> hmm, so, what does that imply, computational stuff?[21:34:58] <ratchetfreak> however most hardware cannot handle that internally so drivers will actually use a 4 component one instead[21:35:03] <ZeroWalker> but you can have different command buffers in different threads?[21:35:08] <ratchetfreak> yeah[21:35:32] <ratchetfreak> in vulkan the driver isn't allowed to lie about which formats are available[21:35:46] <ZeroWalker> but wait, doesn't that just pad the extra byte, so the GPU sees "RGBA" if you will[21:36:03] <ratchetfreak> yeah but opengl is lying about that[21:36:30] <ZeroWalker> yeah so it's internally converting it to 32bit in this case, but in vulkan You have to do the conversion if need be[21:36:30] <ratchetfreak> or at least it's non obvious that it happens[21:36:33] <snyp> ratchetfreak, my vulkan journey is on hold, but can you quickly tell me if I will be able to submit command buffers the same queue from multiple threads?[21:36:47] <snyp> s/the same queue/to the same queue[21:36:55] <turol> afaik no[21:36:58] <ZeroWalker> from my understanding that isn't allowed[21:36:58] <ratchetfreak> queue access must be synchronized IIRC[21:37:02] <turol> submit to a queue is externally synchronized[21:37:21] <snyp> so the building of commands is the main place where parallelism can be achieved compared to opengl?[21:38:06] <snyp> since in opengl all 'commands' like draw and blit are to be done in one thread only. right?[21:38:08] <ratchetfreak> yeah, you can build secondary command buffers, or prebuild future command buffers on other threads[21:38:13] <turol> yes[21:38:21] <turol> also shader compilation can be parallelized[21:38:28] <snyp> oh i see[21:38:28] <ZeroWalker> but i must say, the non state thing (with the binding and stuff) sounds awesome. But i thought vulkan did similar things when i asked here before, maybe i misunderstood[21:38:32] <turol> and resource uploading can happen in parallel[21:38:44] <ratchetfreak> you bind state to the command buffer[21:39:00] <ratchetfreak> azdo is the default[21:43:48] *** cheako <cheako!~cheako@2601:440:4100:4d1f::834> has joined ##vulkan[21:49:22] <ZeroWalker> azdo?[21:49:44] <ratchetfreak> almost zero driver overhead[21:50:04] <ratchetfreak> it's a set of techniques in opengl to reduce the chance of hitting slow paths[21:50:38] <ratchetfreak> includes persistant mapping of buffers, using a staging buffer for texture uploads and downloads[21:50:42] <ratchetfreak> etc[21:53:37] *** jdashg <jdashg!~jdashg@corp-nat.fw1.untrust.mtv2.mozilla.net> has joined ##vulkan[21:56:25] <ZeroWalker> wait so that's in opengl, thought we talked vulkan;o[21:56:50] *** sla_ro|master <sla_ro|master!~sla.ro@78.96.209.89> has quit IRC ()[21:57:09] <ratchetfreak> when talking vulkan a lot of jargon will come over from opengl[21:58:29] <ratchetfreak> what I meant about azdo being the default is that if you want to go non-azdo (aka emulatr old school opengl) you are on the hook for the implementation and will very likely have to create the slow paths yourself[21:59:24] *** MrFlibble <MrFlibble!MrFlibble2@2.124.191.83> has joined ##vulkan[22:04:17] *** snyp <snyp!~Snyp@103.56.236.91> has quit IRC (Quit: Leaving)[22:09:03] <ZeroWalker> kinda lost me there sadly, probably too technical as i don't know wha the difference even would be in the implementation[22:11:40] <ratchetfreak> for example implementing the equivalent of glBufferData requires that you create a new vkBuffer object, allocate a chunk of memory, bind the memory to the object, then if you can map the memory, map it and memcpy[22:12:07] <ratchetfreak> if you cannot map the memory, map a staging buffer and memcpy and queue a buffer copy from staging buffer to the actual buffer[22:12:50] <ZeroWalker> so far so good, a bit confusing with the staging stuff, but the first part is clear[22:13:08] <ZeroWalker> basically you just link a memory chunk you allocate to the object, and then access it via that object[22:13:14] <ratchetfreak> then you have to worry about memory barriers so the data is actually usable by future gpu commands[22:13:44] <ratchetfreak> but not all memory can be mapped into application memory (vram for example)[22:14:20] <ratchetfreak> so you need to go through an intermediary buffer that you can map to application memory[22:15:51] <ZeroWalker> when accessing vram you mean?[22:16:24] <ratchetfreak> from application side, yeah[22:16:35] <ZeroWalker> cause that i get, know you never have direct access to that, probably for very good reasons as well as i guess it's very "messy" from a normal memory standpoint[22:17:26] <turol> not true[22:17:27] *** goiko <goiko!~goiko@unaffiliated/goiko> has quit IRC (Ping timeout: 256 seconds)[22:17:49] <turol> SoCs with integrated CPU and GPU can read and write the same memory[22:18:06] <ZeroWalker> confused to what you are trying to say though. Is it that glBufferData requires you to have a buffer ready when directly there. but vkBuffer allows you to make a buffer for it that you can stick around, so it's a handle to the vram if you will[22:18:24] <ZeroWalker> oh, makes me think of the Gameboy[22:18:26] <turol> and even on PC AMD GPUs let their memory be mapped over the pcie bus[22:18:46] <turol> though it's slower and reading from it is a bad idea[22:18:48] *** derhass <derhass!~derhass@dslb-094-222-155-209.094.222.pools.vodafone-ip.de> has joined ##vulkan[22:18:53] <ZeroWalker> had no clue, but isn't the GPU extremely picky with how things are setup in memory[22:19:02] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has quit IRC (Ping timeout: 256 seconds)[22:19:10] *** goiko <goiko!~goiko@unaffiliated/goiko> has joined ##vulkan[22:19:17] <ZeroWalker> so you can just push a texture somewhere and tell it, the texture is at offset 0x11[22:19:28] <turol> not really[22:19:41] <ratchetfreak> there are alignment requirements[22:19:43] <turol> you still have to go through the vulkan apis so the gpu knows about that stuff properly[22:19:58] <turol> and the os can make the cpu and gpu agree on memory ownership[22:20:40] <ZeroWalker> so, isn't the opengl and vulkan the same in a sense on this part. So how does that go with the azdo stuff and different implementation, kinda lost there xd[22:21:17] <ZeroWalker> (currently at render passes on the video, could that be used to draw different layers in a 2d game, or is it very specialized?)[22:21:34] <ratchetfreak> opengl and vulkan both talk to the same hardware, however vulkan is more explicit in what is really happening[22:22:33] <ZeroWalker> yeah that i get, but in this example, aren't they very similar?[22:22:42] *** cheako <cheako!~cheako@2601:440:4100:4d1f::834> has quit IRC (Ping timeout: 245 seconds)[22:22:57] <ZeroWalker> you have a chunk of memory, tell the API to push it to the VRAM basically[22:23:16] <ZeroWalker> though maybe it's fancy stuff in the vkBuffer object[22:23:34] <ratchetfreak> it's actually all the fancy stuff in the opengl buffer object[22:24:00] <ratchetfreak> because if you call glBufferData again then it orphans the old buffer, allocates a new bit of memory and pushes the data to that[22:24:26] <ratchetfreak> the orphaned buffer then stays alive until the last gpu command that uses it completes and then the memory can be reclaimed[22:25:34] <ZeroWalker> wait you mean so after you give it a chunk of memory, you got no clue how long it's gonna have a second buffer laying around?[22:25:49] <ZeroWalker> meaning it basically allocated memory one extra time[22:26:12] <ratchetfreak> pretty much, though not all that long, the gpu doesn't take that long to empty it's queue of commands[22:28:01] <ZeroWalker> ah, but for the vkBuffer, everything is alive as long as you tell it to?[22:28:10] <ZeroWalker> do you also know how much VRAM you have used precisely?[22:28:22] <ratchetfreak> once memory is bound to a vkBuffer that binding will never change[22:29:02] <ZeroWalker> and that memory, is that accessible without using vkBuffer?[22:29:16] <ZeroWalker> like is it still just a random spot in memory[22:29:48] <ratchetfreak> yeah, vulkan separates memory allocation from binding to buffers/texture[22:30:30] <ratchetfreak> so you can allocate a big buffer and allocate different parts of it to different vkbuffers[22:31:04] <ZeroWalker> ah, but wait, what else could you want in a vkbuffer except textures?[22:31:11] <ZeroWalker> are we talking like the vertex buffers etc?[22:31:27] <ratchetfreak> vertex data, uniforms (like transformation matrices)[22:31:45] <ratchetfreak> vkImage is the texture equivalent[22:33:07] *** slime <slime!~slime73@24.215.81.93> has joined ##vulkan[22:33:33] <ZeroWalker> ah, hmm and these objects, are they used in the vkPipeline thing, or was that something else[22:34:31] <ratchetfreak> in descriptor sets which get bound in the command buffer to let the gpu know where the data comes from[22:35:10] <ratchetfreak> the images can also get put in a framebuffer which are used when starting a renderpass[22:43:34] *** David3k <David3k!~David3k@120.29.112.59> has joined ##vulkan[22:44:43] *** Deluxe <Deluxe!~Deluxe@212.4.150.151> has quit IRC (Read error: Connection reset by peer)[22:45:12] *** threenuc <threenuc!~threenuc@88.156.163.16> has quit IRC (Ping timeout: 245 seconds)[22:52:16] <ZeroWalker> wait, so that's two different things?[22:52:54] <ZeroWalker> Just completed the video (QA time), was really interesting, loved the concept on a ton of stuff;d[23:04:09] *** woddy <woddy!~woddy@unaffiliated/woddy> has joined ##vulkan[23:05:36] <woddy> so[23:05:43] <woddy> khronos claims that vulkan will replace openCL[23:05:51] <woddy> is that to be taken serious?[23:06:20] <ZeroWalker> isn't openCL basicall an API that's like a "computation shader"? (just guessing)[23:06:46] <woddy> its for acceleration by using gpu, multi core CPUs, or even by now FPGAs[23:07:10] <woddy> khronos claiemd on the one hand vulkan will sort of merge openCL and openGL into one, on the other hand they claim Vulkan will not compete with openGL[23:07:10] <ZeroWalker> yeah but when it's used by the GPU, isn't the principle the same as a computation shader?[23:07:14] <woddy> as openGL is higher level than Vulkan[23:07:14] <ZeroWalker> doing computation on the gpu[23:07:21] <woddy> yes[23:07:36] <woddy> but for fpga e.g. it generates code to configure it[23:07:43] <woddy> thats quite different[23:07:52] <ZeroWalker> yeah the first doesn't make sense, cause as far as i know, OpenGL will be it's own thing and should not be seen as a Vulkan rival or something[23:08:03] <woddy> correct[23:08:04] <woddy> the thing is[23:08:07] <woddy> both claims are by khronos[23:08:09] <ZeroWalker> however, i could see that OpenCL would be in Vulkan so to speak[23:08:16] <ZeroWalker> maybe they mean like[23:08:19] <|3b|> where did they claim that?[23:08:24] <ZeroWalker> if you use OpenGL, you have to use OpenCL as well[23:08:33] <woddy> |3b|, wait a moment, I'll look it up again[23:08:34] <ZeroWalker> but in vulkan, if you use vulkan it can also do the opencl part?[23:08:37] *** cheako <cheako!~cheako@2601:440:4100:4d1f::834> has joined ##vulkan[23:08:41] <Yaniel> woddy: those claims are not in conflict though[23:08:42] <ZeroWalker> making it "both in one" in those cases[23:08:49] <|3b|> compute shaders are similar to OpenCL, but fairly different feature set[23:09:11] <Yaniel> vulkan is low level, gl is high level, both have a place[23:09:29] <woddy> ok sorry[23:09:30] <woddy> Vulkan and OpenCL will merge into a single API[23:09:34] <woddy> apparently misread somewhere[23:09:53] *** nsf <nsf!~nsf@jiss.convex.ru> has quit IRC (Quit: WeeChat 2.0.1)[23:09:57] <Yaniel> one interesting thing would be to see a portable gl implementation on top of vulkan[23:10:04] <woddy> now what will that look like?[23:10:06] <Yaniel> ANGLE might get there actually[23:10:39] <ratchetfreak> it'll start with webgl on vulkan I believe[23:10:43] <|3b|> though considering how well nvidia doesn't support opencl, forcing them to add the opencl SPIRV stuff to vulkan might be nice :)[23:11:28] <ZeroWalker> nvidia doesn't support it?[23:11:32] <ZeroWalker> that's weird[23:11:38] *** davr0s <davr0s!~textual@host86-157-70-106.range86-157.btcentralplus.com> has joined ##vulkan[23:11:39] <ZeroWalker> i guess they use there thing that i can't remember the name on[23:11:45] <woddy> CUDA?[23:11:47] <ZeroWalker> yeah[23:11:51] <|3b|> nvidia supports opencl 1.2 last i looked, and that was years after 1.2 was released[23:12:10] <|3b|> along with a few random 2.x functions or something like that[23:12:26] <ratchetfreak> maybe someone will implement opencl on top of cuda?[23:14:25] <woddy> what do you guys use vulkan for?[23:14:44] <ZeroWalker> hmm wonder what video i should see next[23:15:14] <woddy> so as an openCL user[23:15:22] <woddy> do I understand this right: I will end up having to learn vulkan[23:15:39] <ZeroWalker> i would probably say no[23:15:41] <woddy> and they will not continue openCL as an own project[23:15:42] <woddy> mhm[23:15:48] <ZeroWalker> more, if you use vulkan you don't need opencl[23:15:52] <ZeroWalker> that's what i take from it[23:16:21] <ZeroWalker> may be wrong, but would feel weird if OpenCL became vulkan itself[23:16:33] <Yaniel> not that weird actually[23:16:41] <Yaniel> they share many similarities already[23:16:56] <ZeroWalker> yeah but i mean like, how would things work out[23:16:59] <Yaniel> and you can use vulkan headlessly i.e. without any graphical output[23:17:06] <woddy> "The OpenCL working group has taken the decision to converge its roadmap with Vulkan, and use Vulkan as the basis for the next generation of explicit compute APIs – this also provides the opportunity for the OpenCL roadmap to merge graphics and compute."[23:17:26] <ZeroWalker> would it be like, oh OpenCL is not compatible with Vulkan code here blabla, sounds like a big mess if they become one another[23:17:36] <ZeroWalker> hmm[23:17:42] <ZeroWalker> okay i am lost, but that's not new[23:17:51] <woddy> ZeroWalker, right[23:17:54] <woddy> but its still not clearer[23:17:56] <Yaniel> the current opencl will stay as it is[23:17:57] <woddy> than it was 9 months ago[23:18:02] <woddy> when it was made into a press release[23:18:13] <Yaniel> 2.1 or whatever[23:18:28] <ZeroWalker> so can we basically take that as[23:18:38] <ZeroWalker> OpenCL x.x == Vulkan[23:18:48] <woddy> ZeroWalker, thats what I'm wondering about[23:18:50] <Yaniel> opencl-next i.e. 3.0 will probably become part of vulkan[23:18:58] <woddy> Yaniel, ok, thats what I wanted to know[23:19:15] <ZeroWalker> ah, so, 3.0 will not be available as 3.0 then, but you need vulkan to access those functions?[23:19:33] <ratchetfreak> though that would probably also include vulkan 2.0 getting some opencl features[23:19:51] * |3b| wouldn't be surprised if it only needed a simplified subset of vulkan for pure compute in that case[23:20:31] <woddy> vulkan can easily combine heterogenous computing[23:20:37] <woddy> different CPUs, GPUs, FPGAs[23:20:41] <woddy> ?[23:20:43] <ZeroWalker> what vulkan is here now, 1.1?[23:20:44] <woddy> I doubt that[23:20:49] <woddy> esp FPGA side[23:20:55] <woddy> which is what I care most about[23:20:56] <Yaniel> of course not, it's a graphics api[23:21:00] <woddy> so no[23:21:00] <|3b|> presumably they would add extensions for that[23:21:02] <Yaniel> right now that is[23:21:17] <woddy> well OpenCL has that FPGA capability[23:21:19] <Yaniel> vulkan 2.0 is an entirely different story[23:21:35] <woddy> but yeah I have some feeling they will just make it all "Vulkan"[23:21:38] <ratchetfreak> vulkan is at 1.0.69[23:21:51] <Yaniel> that's literally what the announcement says[23:21:55] <woddy> ok[23:21:58] <woddy> so I got it right, thanks[23:22:11] <woddy> just wante dsome random dude on irc to confirm it[23:23:24] <ZeroWalker> hahaha XD[23:23:37] <ZeroWalker> yeah, when you get some random dude on irc to confirm things, you know you are on the right track[23:24:46] <|3b|> https://www.pcper.com/reviews/Graphics-Cards/Follow-Neil-Trevett-and-Tom-Olson-Khronos-Group-Discuss-OpenCL-and-Vulkan-Roa[23:24:54] <woddy> sorry for the "newbie" question: what is that actually good for? why would people want lower than OpenGL level graphics librarys? has that any applications outside gaming/animation films?[23:25:07] <ZeroWalker> Fats, saw the video;d[23:26:33] <Yaniel> woddy: what is? vulkan?[23:26:41] <|3b|> pretty much anything that uses OpenGL could find vulkan useful[23:26:44] <woddy> yes, I don't want to be annoying or troll or anything[23:26:47] *** Berserker66 <Berserker66!~Fabian_Di@dslb-088-065-161-171.088.065.pools.vodafone-ip.de> has joined ##vulkan[23:27:01] <woddy> I'm genuinely curious[23:27:02] <Yaniel> the gl api was designed in the 90s[23:27:23] <Yaniel> tech evolved, things that were good ideas back then are not good ideas anymore[23:27:41] <woddy> yeah but apparently openGL will not be replaced[23:27:43] <Yaniel> also global state is pure cancer[23:27:44] <|3b|> gl "helpfully" hides a bunch of things, making performance hard to predict, and a lot of the abstractions in GL haven't aged well[23:27:55] <Yaniel> so anyone who wants to wrap a graphcis api[23:28:05] <|3b|> lots of old GL code won't be replaced, so opengl itself can't be :)[23:28:11] <Yaniel> such as a game engine, web browser or windowing system[23:28:22] <ratchetfreak> for an example of how it evolved I wrote up a short history of how you passed vertex information to opengl: https://handmade.network/wiki/2821-the_history_of_opengl_vertex_data[23:28:37] <Yaniel> they all have a hard time doing so and the results tend to be brittle or slow[23:28:57] <|3b|> and lots of things don't push the edges of GL enough to care[23:28:57] <Yaniel> with vulkan there's explicit control over everything so wrapping becomes a lot more doable[23:29:03] <woddy> so this will spawn off most likely specialized graphics librarys?[23:29:17] <woddy> not be immediately used in applications[23:29:25] <Yaniel> there are already specialized graphics libraries on top of gl[23:29:35] <woddy> yeh of course[23:29:41] <Yaniel> but yes, that kind of library is likely to become more common/popular[23:30:15] <Yaniel> say, bgfx[23:30:21] <Yaniel> or sdl[23:30:22] <ratchetfreak> and several approaches are possible to how things are abstracted instead of being railroaded to opengl[23:31:41] <Yaniel> that too[23:32:43] <Yaniel> for example a graphics library in a functional language is much easier to build with vulkan, specifically because it's not based on global state[23:33:31] *** cheako <cheako!~cheako@2601:440:4100:4d1f::834> has quit IRC (Ping timeout: 245 seconds)[23:34:12] *** cheako <cheako!~cheako@2601:440:4100:4d1f::834> has joined ##vulkan[23:46:01] *** cheako <cheako!~cheako@2601:440:4100:4d1f::834> has quit IRC (Ping timeout: 245 seconds)[23:46:35] *** BearishMushroom <BearishMushroom!~BearishMu@82-209-154-59.cust.bredband2.com> has quit IRC (Read error: Connection reset by peer)[23:48:43] *** snyp <snyp!~Snyp@103.56.236.64> has joined ##vulkan[23:50:12] <ZeroWalker> well should go to bed soon, must say i feel some motivation trying vulkan out, but then again i have only seen an overview, not any practical code[23:59:27] *** glima <glima!~glima@enlightenment/developer/glima> has quit IRC (Remote host closed the connection)