February 12, 2017 
< | 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 12, 2017 [00:01:14] *** nsf <nsf!~nsf@jiss.convex.ru> has quit IRC (Quit: WeeChat 1.7)[00:14:02] *** blaidddwr <blaidddwr!~blaidddwr@209.107.214.72> has joined ##vulkan[00:27:32] *** xissburg <xissburg!~xissburg@unaffiliated/xissburg> has joined ##vulkan[00:44:09] *** blaidddwr <blaidddwr!~blaidddwr@209.107.214.72> has quit IRC (Quit: Namaste)[00:51:27] *** Jackneill_ <Jackneill_!~Jackneill@unaffiliated/jackneill> has quit IRC (Remote host closed the connection)[00:51:36] *** narann <narann!~narann@2a01:e34:ee2e:4830:45f1:7f18:b91b:e12a> has quit IRC (Quit: Leaving)[01:06:38] *** bjz <bjz!~bjz@14-201-215-168.tpgi.com.au> has joined ##vulkan[01:07:27] *** bjz <bjz!~bjz@14-201-215-168.tpgi.com.au> has quit IRC (Client Quit)[01:08:20] *** bjz <bjz!~bjz@14-201-215-168.tpgi.com.au> has joined ##vulkan[01:22:25] *** spossiba <spossiba!~spossiba@unaffiliated/stryx/x-3871776> has quit IRC (Ping timeout: 245 seconds)[01:25:44] *** spossiba <spossiba!~spossiba@198.98.53.118> has joined ##vulkan[01:25:45] *** spossiba <spossiba!~spossiba@198.98.53.118> has quit IRC (Changing host)[01:25:45] *** spossiba <spossiba!~spossiba@unaffiliated/stryx/x-3871776> has joined ##vulkan[02:11:33] *** ravior <ravior!~crapitea@5-13-152-135.residential.rdsnet.ro> has quit IRC (Quit: Konversation terminated!)[02:14:12] *** FiveBroDeepBook <FiveBroDeepBook!~gk.1wm.su@2606:f180:1:2ea:2ea:af60:f0b8:8f26> has joined ##vulkan[02:14:13] *** FiveBroDeepBook <FiveBroDeepBook!~gk.1wm.su@2606:f180:1:2ea:2ea:af60:f0b8:8f26> has left ##vulkan[02:32:32] *** bjz <bjz!~bjz@14-201-215-168.tpgi.com.au> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[02:53:10] *** spossiba <spossiba!~spossiba@unaffiliated/stryx/x-3871776> has quit IRC (Ping timeout: 255 seconds)[02:56:13] *** spossiba <spossiba!~spossiba@unaffiliated/stryx/x-3871776> has joined ##vulkan[03:27:14] *** bjz <bjz!~bjz@14-201-215-168.tpgi.com.au> has joined ##vulkan[03:43:55] *** bjz <bjz!~bjz@14-201-215-168.tpgi.com.au> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[03:58:47] *** bjz <bjz!~bjz@14-201-215-168.tpgi.com.au> has joined ##vulkan[04:18:32] *** GMpow2_2 <GMpow2_2!~5@55d409f1.access.ecotel.net> has joined ##vulkan[04:21:53] *** GMpow2 <GMpow2!~5@55d40e72.access.ecotel.net> has quit IRC (Ping timeout: 240 seconds)[04:34:33] *** GMpow2_2 <GMpow2_2!~5@55d409f1.access.ecotel.net> has quit IRC (Quit: Leaving)[04:34:42] *** GMpow2_2 <GMpow2_2!~5@55d409f1.access.ecotel.net> has joined ##vulkan[04:34:51] *** GMpow2_2 is now known as GMpow2[05:07:16] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-82s3g7omx242auk5xjq.18120a2.ip6.access.telenet.be> has quit IRC (Ping timeout: 255 seconds)[05:07:40] *** herbmillerjr <herbmillerjr!~herb@c-76-120-173-141.hsd1.pa.comcast.net> has quit IRC (Quit: Konversation terminated!)[05:19:48] *** GMpow2 <GMpow2!~5@55d409f1.access.ecotel.net> has quit IRC (Ping timeout: 240 seconds)[05:25:13] *** BearishMushroom <BearishMushroom!~BearishMu@90-231-174-194-no159.tbcn.telia.com> has quit IRC (Read error: Connection reset by peer)[05:43:18] *** bjz <bjz!~bjz@14-201-215-168.tpgi.com.au> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[06:05:35] *** bjz <bjz!~bjz@pa49-184-157-92.pa.vic.optusnet.com.au> has joined ##vulkan[06:09:30] *** ville <ville!~ville@37-33-6-206.bb.dnainternet.fi> has quit IRC (Ping timeout: 245 seconds)[06:18:01] *** bjz <bjz!~bjz@pa49-184-157-92.pa.vic.optusnet.com.au> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[06:28:18] *** lpghatguy <lpghatguy!~LPGhatguy@63.153.99.104> has joined ##vulkan[06:29:41] *** tambre <tambre!~tambre@1ad9-3c0f-7eab-c103-0e80-8a31-07d0-2001.dyn.estpak.ee> has joined ##vulkan[07:01:42] *** FiveBroDeepBook <FiveBroDeepBook!~gk.1wm.su@2001:590:1405:72:72:3163:b97e:f4f0> has joined ##vulkan[07:01:44] *** FiveBroDeepBook <FiveBroDeepBook!~gk.1wm.su@2001:590:1405:72:72:3163:b97e:f4f0> has left ##vulkan[07:23:28] *** spossiba <spossiba!~spossiba@unaffiliated/stryx/x-3871776> has quit IRC (Ping timeout: 255 seconds)[07:25:46] *** spossiba <spossiba!~spossiba@unaffiliated/stryx/x-3871776> has joined ##vulkan[08:05:40] *** w-t-h_ <w-t-h_!~chatzilla@72.67.52.110> has quit IRC (Ping timeout: 240 seconds)[08:24:01] *** sla_ro|master <sla_ro|master!~sla.ro@95.76.45.217> has joined ##vulkan[08:41:33] *** ville <ville!~ville@178-55-91-48.bb.dnainternet.fi> has joined ##vulkan[08:43:23] *** nsf <nsf!~nsf@jiss.convex.ru> has joined ##vulkan[08:51:11] *** slidercrank <slidercrank!~slidercra@unaffiliated/slidercrank> has quit IRC (Remote host closed the connection)[08:51:31] *** slidercrank <slidercrank!~slidercra@unaffiliated/slidercrank> has joined ##vulkan[08:56:43] *** bjz <bjz!~bjz@14-201-122-110.static.tpgi.com.au> has joined ##vulkan[09:01:00] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has joined ##vulkan[09:05:30] *** slidercrank <slidercrank!~slidercra@unaffiliated/slidercrank> has quit IRC (Ping timeout: 260 seconds)[09:17:25] *** tacchinotacchi <tacchinotacchi!~tacchinot@net-93-144-206-17.cust.vodafonedsl.it> has quit IRC (Read error: Connection reset by peer)[09:17:48] *** tacchinotacchi <tacchinotacchi!~tacchinot@net-93-144-206-17.cust.dsl.teletu.it> has joined ##vulkan[09:33:16] *** john___ <john___!~john@host86-143-93-221.range86-143.btcentralplus.com> has joined ##vulkan[09:34:05] *** john1 <john1!~john@host86-143-93-221.range86-143.btcentralplus.com> has quit IRC (Ping timeout: 260 seconds)[09:43:29] *** tacchinotacchi_ <tacchinotacchi_!~tacchinot@net-93-144-206-17.cust.vodafonedsl.it> has joined ##vulkan[09:43:29] *** tacchinotacchi <tacchinotacchi!~tacchinot@net-93-144-206-17.cust.dsl.teletu.it> has quit IRC (Read error: Connection reset by peer)[09:49:42] *** Kingsquee <Kingsquee!~kingsley@d172-218-58-109.bchsia.telus.net> has joined ##vulkan[09:58:02] *** ShadowIce <ShadowIce!~pyoro@unaffiliated/shadowice-x841044> has joined ##vulkan[10:01:01] *** echotangoecho <echotangoecho!~echotango@dhcp-089-098-177-067.chello.nl> has joined ##vulkan[10:14:51] *** nsf <nsf!~nsf@jiss.convex.ru> has quit IRC (Quit: WeeChat 1.7)[10:38:13] <ville> anyone know why vk.xml uses different "layout" for pointer-to-functions and functions? namely the former does not have parameters in <param> tags while the latter does. by not having <param> tags the "parameter name" and possible leading "const" of the next parameter gets run into single text block and needs to be parsed out "by hand"[10:40:37] <ville> take PFN_vkDebugReportCallbackEXT for example, the name of the parameter messageCode and the leading const of the next parameter pLayerPrefix are in the same node.[10:42:27] <ville> https://github.com/KhronosGroup/Vulkan-Docs/blob/1.0/src/spec/vk.xml#L408[10:47:01] *** ville <ville!~ville@178-55-91-48.bb.dnainternet.fi> has quit IRC (Ping timeout: 258 seconds)[10:48:50] *** ville <ville!~ville@87-95-117-14.bb.dnainternet.fi> has joined ##vulkan[10:54:32] *** ravior <ravior!~crapitea@5-13-152-135.residential.rdsnet.ro> has joined ##vulkan[11:01:34] *** ville <ville!~ville@87-95-117-14.bb.dnainternet.fi> has quit IRC (Ping timeout: 264 seconds)[11:03:15] *** ville <ville!~ville@87-95-193-95.bb.dnainternet.fi> has joined ##vulkan[11:04:02] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-82s3g7omx242auk5xjq.18120a2.ip6.access.telenet.be> has joined ##vulkan[11:08:37] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-82s3g7omx242auk5xjq.18120a2.ip6.access.telenet.be> has quit IRC (Ping timeout: 255 seconds)[11:15:21] *** nsf <nsf!~nsf@jiss.convex.ru> has joined ##vulkan[11:17:28] *** HuntsMan <HuntsMan!~hunts@cpc104822-sgyl39-2-0-cust136.18-2.cable.virginm.net> has quit IRC (Quit: Konversation terminated!)[11:24:55] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has quit IRC (Ping timeout: 260 seconds)[11:34:12] *** john <john!~john@host86-147-123-91.range86-147.btcentralplus.com> has joined ##vulkan[11:34:19] *** john is now known as Guest31438[11:36:05] *** john___ <john___!~john@host86-143-93-221.range86-143.btcentralplus.com> has quit IRC (Ping timeout: 240 seconds)[11:50:13] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has joined ##vulkan[11:51:34] *** echotangoecho <echotangoecho!~echotango@dhcp-089-098-177-067.chello.nl> has quit IRC (Quit: leaving)[11:52:43] *** tacchinotacchi_ <tacchinotacchi_!~tacchinot@net-93-144-206-17.cust.vodafonedsl.it> has quit IRC (Read error: Connection reset by peer)[11:56:40] <Cheery> if you wanted to implement something like webgpu on vulkan, what should you consider?[11:57:35] *** TechnoCrunch <TechnoCrunch!~TechnoCru@101.100.137.146> has quit IRC (Read error: Connection reset by peer)[11:57:41] <Cheery> there's not official spec, but the idea is clear: a GPU API that has as much detail abstracted away as possible.[11:59:19] <Cheery> the gpu allocator is obvious one.[11:59:23] *** tacchinotacchi <tacchinotacchi!~tacchinot@net-93-144-206-17.cust.vodafonedsl.it> has joined ##vulkan[12:00:01] <Cheery> but things like the memory views, fences and semaphores seem something you could hide too, but it's not obvious how.[12:01:16] <exDM69> Cheery: 1st) go and tell apple that their api proposal is difficult to implement efficiently with vulkan[12:01:57] <exDM69> e.g. setVertexBuffer() / setIndexBuffer() is difficult to implement with descriptor sets[12:02:29] <exDM69> they should have honestly named it WebMetal, because that's what it is[12:02:36] <exDM69> and then try reconciling things later[12:02:52] <Cheery> exDM69: also the createQueue seems like difficult to implement.[12:03:15] *** bjz_ <bjz_!~bjz@104.222.140.127> has joined ##vulkan[12:03:35] *** lpghatguy <lpghatguy!~LPGhatguy@63.153.99.104> has quit IRC (Quit: I'll be back.)[12:03:40] <exDM69> not difficult, but inefficient (you'd need to add some kind of queue sharing and add mutexes, etc if multithreading is a concern)[12:04:14] *** bjz <bjz!~bjz@14-201-122-110.static.tpgi.com.au> has quit IRC (Ping timeout: 240 seconds)[12:05:10] <Cheery> exDM69: basically I wonder what would a webvulkan look like.[12:06:10] <exDM69> IMO someone should just make a proposal to export the vulkan api as is to be usable from WASM[12:06:21] <exDM69> figure out a way to do that and the rest should work out fine[12:06:47] <exDM69> but then there are people who insist on having some kind of application level safety, which is a completely stillborn idea[12:06:59] <tomaka> for objects that are created at initialization (like pipeline objects) make the validation layers mandatory[12:07:07] <exDM69> run it in a different process and let it segfault[12:07:19] <tomaka> for the GPU behavior, add an extension that makes behaviors defined instead of undefined (similar to the robustBufferAccess featuyre)[12:07:39] <exDM69> if there's a driver/kernel bug, it's already exploitable from WebGL (as evidenced by the recent shader fuzzing articles)[12:07:52] <ville> webgpu? that proposal from apple from past week? i didn't bother to read because it was from apple[12:09:15] <Cheery> exDM69: personally, I'm looking towards improving this: https://github.com/cheery/lever/blob/master/samples/vulkan/sample3.lc[12:10:46] <Cheery> exDM69: and I'd be looking to get it be cleaner than this: https://github.com/cheery/lever/blob/master/samples/gl/1.lc[12:14:56] <Cheery> exDM69: exporting the vulkan API to WASM would probably be feasible. But the challenges remain. You need layers of abstractions to get started.[12:15:15] <Cheery> and yeah, it'd be probably less risky if you expect the layers to be removable.[12:16:45] <Cheery> that. or then you keep using gl and making the transition more expensive further you go.[12:29:33] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-82s3g7omx242auk5xjq.18120a2.ip6.access.telenet.be> has joined ##vulkan[12:30:51] *** echotangoecho <echotangoecho!~echotango@dhcp-089-098-177-067.chello.nl> has joined ##vulkan[12:36:41] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-82s3g7omx242auk5xjq.18120a2.ip6.access.telenet.be> has quit IRC (Read error: Connection reset by peer)[12:37:09] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-82s3g7omx242auk5xjq.18120a2.ip6.access.telenet.be> has joined ##vulkan[12:48:35] *** Jackneill_ <Jackneill_!~Jackneill@unaffiliated/jackneill> has joined ##vulkan[12:55:31] *** Kingsquee <Kingsquee!~kingsley@d172-218-58-109.bchsia.telus.net> has quit IRC (Quit: https://i.imgur.com/qicT3GK.gif)[12:59:11] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-82s3g7omx242auk5xjq.18120a2.ip6.access.telenet.be> has quit IRC (Read error: Connection reset by peer)[12:59:34] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-82s3g7omx242auk5xjq.18120a2.ip6.access.telenet.be> has joined ##vulkan[13:07:59] *** BearishMushroom <BearishMushroom!~BearishMu@90-231-174-194-no159.tbcn.telia.com> has joined ##vulkan[13:09:53] *** FiveBroDeepBook <FiveBroDeepBook!~gk.1wm.su@46.148.182.82> has joined ##vulkan[13:09:54] *** FiveBroDeepBook <FiveBroDeepBook!~gk.1wm.su@46.148.182.82> has left ##vulkan[13:30:25] *** afl_ext <afl_ext!~afl_ext3@unaffiliated/afl-ext/x-2796036> has joined ##vulkan[13:39:24] *** tacchinotacchi <tacchinotacchi!~tacchinot@net-93-144-206-17.cust.vodafonedsl.it> has quit IRC (Read error: Connection reset by peer)[13:39:40] *** tacchinotacchi <tacchinotacchi!~tacchinot@net-93-144-206-17.cust.dsl.teletu.it> has joined ##vulkan[13:43:44] *** Timbo <Timbo!~tma@tremulous/developer/timbo> has quit IRC (Ping timeout: 260 seconds)[14:33:20] <Cheery> I had forgotten you can create buffer before associating memory to it.[14:34:40] *** afl_ext <afl_ext!~afl_ext3@unaffiliated/afl-ext/x-2796036> has quit IRC (Quit: Leaving)[14:34:55] *** afl_ext <afl_ext!~afl_ext3@unaffiliated/afl-ext/x-2796036> has joined ##vulkan[14:39:10] <sharpneli> You have to create it before associating memory to it.[14:39:39] <sharpneli> However the only thing you can do after creating it is to associate memory. Anything else becomes available only after that (descriptor sets etc)[14:39:40] *** tacchinotacchi <tacchinotacchi!~tacchinot@net-93-144-206-17.cust.dsl.teletu.it> has quit IRC (Ping timeout: 240 seconds)[14:47:13] *** tacchinotacchi <tacchinotacchi!~tacchinot@net-93-144-206-17.cust.dsl.teletu.it> has joined ##vulkan[14:53:42] *** sla_ro|master <sla_ro|master!~sla.ro@95.76.45.217> has quit IRC ()[15:01:10] *** Garner <Garner!~tywin@5.196.69.15> has quit IRC (Read error: Connection reset by peer)[15:29:59] *** feliwir <feliwir!Elite17837@gateway/shell/elitebnc/x-clmspwfpoetyijxm> has quit IRC (Excess Flood)[15:32:01] *** feliwir <feliwir!Elite17837@gateway/shell/elitebnc/x-thgtguslonisclrr> has joined ##vulkan[15:36:57] *** spossiba <spossiba!~spossiba@unaffiliated/stryx/x-3871776> has quit IRC (Ping timeout: 240 seconds)[15:37:57] *** spossiba <spossiba!~spossiba@unaffiliated/stryx/x-3871776> has joined ##vulkan[15:38:44] *** ravior <ravior!~crapitea@5-13-152-135.residential.rdsnet.ro> has quit IRC (Quit: Konversation terminated!)[15:43:47] *** Timbo <Timbo!~tma@cpc102378-sgyl38-2-0-cust55.18-2.cable.virginm.net> has joined ##vulkan[15:52:09] *** xhsmd <xhsmd!~xhsmd@2a00:23c4:ce81:ea00:7a28:3a11:2bd3:9c54> has joined ##vulkan[15:54:24] <ville> anyone know why vk.xml uses different "layout" for pointer-to-functions and functions? namely the former does not have parameters in <param> tags while the latter does. by not having <param> tags the "parameter name" and possible leading "const" of the next parameter gets run into single text block and needs to be parsed out "by hand"[15:54:30] <ville> https://github.com/KhronosGroup/Vulkan-Docs/blob/1.0/src/spec/vk.xml#L408[15:55:18] <ratchetfreak> they focused more on getting it together and parsable into C than something more general that's properly usable in other languages[15:56:35] <Cheery> despite that it's doable.[15:57:55] <Cheery> I wonder what else I could do here to make it cleaner to use: https://github.com/cheery/lever/blob/master/samples/warpgpu/app0.lc[16:00:42] <ratchetfreak> maybe https://github.com/NicolBolas/New-Vulkan-XML-Format will be of help[16:01:40] *** nsf <nsf!~nsf@jiss.convex.ru> has quit IRC (Quit: WeeChat 1.7)[16:10:42] *** AlexAlte- is now known as AlexAltea[16:18:59] <Cheery> https://github.com/cheery/lever/blob/master/samples/warpgpu/app0.lc added DEP: -comments.[16:19:38] <Cheery> I need to understand something about this.[16:20:10] *** afl_ext <afl_ext!~afl_ext3@unaffiliated/afl-ext/x-2796036> has quit IRC (Read error: Connection reset by peer)[16:23:07] <Cheery> descriptor set layout is there for explaining what's in the descriptor set.[16:23:28] <Cheery> if you want to think of it as something, it'd be the layout of the variables in the shader.[16:24:15] <Cheery> but the pipeline layout may consist of several descriptor sets.[16:25:40] <Cheery> the pipeline layout of this thing attaches into a pipeline, everything else including the descriptor sets themselves is pushed directly into command buffer.[16:30:02] <Cheery> pipeline doesn't depend on framebuffer used for rendering, but it depends on render pass and the render pass has to know the formats of attachments.[16:31:29] <Cheery> framebuffer forms the specific target for rendering. But it can be chosen in the beginning of command buffer.[16:32:27] <Cheery> semaphore is required everywhere where there is a read-write dependency.[16:32:49] <Cheery> or where a barrier is needed.[16:33:07] <ratchetfreak> semaphore is only needed for cross queue sync[16:33:43] <Cheery> ok. that I didn't know. So I can remove all semaphores here..[16:33:55] <ratchetfreak> except the ones needed for present[16:34:44] <Cheery> oh okay. so that's thought as a cross-queue sync.[16:35:46] <Cheery> maybe this starts to have a structure and sense in here.[16:36:32] <Cheery> the only thing is the pipeline barriers.[16:37:28] <ratchetfreak> in the normal case (update uniforms, draw, present) you don't need any explicit vkPipelineBarrier[16:37:53] <ratchetfreak> you can fold that into the renderpass using the subpass dependency from/to EXTERNAL[16:39:13] <Cheery> you mean the renderpass itself can communicate that the pass renders for presentation.[16:39:42] <ratchetfreak> you can set the final layout of the color attachment to layout_present[16:40:18] <Cheery> and I don't need to worry about the initial layout as the attachment is cleared?[16:40:26] <ratchetfreak> you can set that to undefined[16:40:57] <ratchetfreak> and in the subpass to colorattachment optimal[16:41:25] *** xhsmd <xhsmd!~xhsmd@2a00:23c4:ce81:ea00:7a28:3a11:2bd3:9c54> has quit IRC (Remote host closed the connection)[16:44:42] <Cheery> can I implement an automatic insertion of barriers?[16:45:37] <ratchetfreak> based on user code? I wouldn't start on that.[16:46:16] <Cheery> what would you start on instead?[16:46:34] <ratchetfreak> what's the goal?[16:50:00] <Cheery> the goal is to build abstractions that provide some sensible default, but can be teared out if there comes a need to optimize.[16:52:32] <Cheery> I think I can wrap lots of the pools here into some sort of instance already.[16:54:10] <Cheery> as well as abstract lot of the framebuffer things and maybe drop semaphores into swapchain.[16:55:50] <ratchetfreak> I think getting something sane out of the pipeline creation would be be a better goal[16:55:59] <ratchetfreak> IMO that part of vulkan is a bit convoluted[16:56:21] <Cheery> https://github.com/cheery/lever/blob/master/samples/warpgpu/app0.lc#L215[16:56:31] <Cheery> yeah. I can agree with that.[16:56:50] <Cheery> pipeline creation really blows everything on your face at once.[16:58:48] *** feliwir <feliwir!Elite17837@gateway/shell/elitebnc/x-thgtguslonisclrr> has left ##vulkan ("Leaving")[16:59:14] *** afl_ext <afl_ext!~afl_ext3@unaffiliated/afl-ext/x-2796036> has joined ##vulkan[16:59:58] <Cheery> it appears it can be built by composition. that makes it slightly easier to work with.[17:00:17] <Cheery> not much thought.[17:00:50] <ratchetfreak> something simpler would be nice, like for example doing a dry run of a renderpass with an opengl style API and building everything needed from that[17:02:57] <Cheery> the base pipeline handle allows me to define a default pipeline and then overlay the diff over it, right?[17:03:26] *** TheSilentLink <TheSilentLink!~TheSilent@unaffiliated/thesilentlink> has quit IRC (Quit: ZNC 1.6.3+deb1+jessie0 - http://znc.in)[17:03:56] *** TheSilentLink <TheSilentLink!~TheSilent@unaffiliated/thesilentlink> has joined ##vulkan[17:04:10] <Cheery> that way probably over half of this pipeline state would be dropped.[17:05:20] <Cheery> also for resizable window rendering you probably want to setup viewportState as dynamic.[17:06:19] <ratchetfreak> or create a new renderpass, resizing will require a new swapchain anyway, and it's rare enough that lag is expect[17:08:25] <Cheery> something I thought about while ago.. this all feels like it should instead be a chart, which is flushed if some condition changes unfavorably.[17:12:58] *** nsf <nsf!~nsf@jiss.convex.ru> has joined ##vulkan[17:14:07] *** nitroxis <nitroxis!n@6.nxs.re> has quit IRC (Remote host closed the connection)[17:14:59] *** nitroxis <nitroxis!n@6.nxs.re> has joined ##vulkan[17:22:33] *** pent <pent!~pent@138.197.129.246> has joined ##vulkan[17:29:13] *** FiveBroDeepBook <FiveBroDeepBook!~gk.1wm.su@2606:f180:1:df:df:121e:9695:caa6> has joined ##vulkan[17:29:14] *** FiveBroDeepBook <FiveBroDeepBook!~gk.1wm.su@2606:f180:1:df:df:121e:9695:caa6> has left ##vulkan[17:40:25] *** sla_ro|master <sla_ro|master!~sla.ro@95.76.45.217> has joined ##vulkan[17:49:40] *** echotangoecho <echotangoecho!~echotango@dhcp-089-098-177-067.chello.nl> has quit IRC (Ping timeout: 240 seconds)[18:01:03] <Cheery> ratchetfreak: it'd seem that it would make sense to lug lot of the pipeline state from the render pass.[18:01:27] *** GMpow2 <GMpow2!~5@55d409f1.access.ecotel.net> has joined ##vulkan[18:03:11] *** GMpow2 <GMpow2!~5@55d409f1.access.ecotel.net> has quit IRC (Client Quit)[18:03:19] *** GMpow2 <GMpow2!~5@55d409f1.access.ecotel.net> has joined ##vulkan[18:04:27] <ville> i suppose i could open a github issue on the way pointer-to-function's parameters are tagged in the xml[18:27:23] <Cheery> descriptor pools and descriptor set layouts hm. :/[18:27:50] <Cheery> one descriptor set layout can get several descriptors of various kinds.[18:28:08] <Cheery> and descriptor pool has limited amount of each.[18:28:12] <Cheery> it's kind of annoying setup.[18:31:16] *** LanDi <LanDi!~landi@191.33.11.30> has joined ##vulkan[18:33:48] *** Ralith <Ralith!ralithrali@gateway/shell/matrix.org/x-jvzznrgudbxcsijg> has quit IRC (Ping timeout: 240 seconds)[18:33:55] *** karroffel <karroffel!karroffelm@gateway/shell/matrix.org/x-lfcfcpqxdzdrfoer> has quit IRC (Ping timeout: 258 seconds)[18:34:25] *** kikijiki[m] <kikijiki[m]!kikijikima@gateway/shell/matrix.org/x-qbsmiphutdrohfae> has quit IRC (Ping timeout: 255 seconds)[18:36:08] *** atexborman[m] <atexborman[m]!atexborman@gateway/shell/matrix.org/x-giitrclcdgnsdplp> has quit IRC (Ping timeout: 256 seconds)[18:36:08] *** bgrayburn[m] <bgrayburn[m]!bgrayburnm@gateway/shell/matrix.org/x-tjtjurctlmcedfmq> has quit IRC (Ping timeout: 256 seconds)[18:36:13] *** Wallbraker <Wallbraker!wallbraker@gateway/shell/matrix.org/x-micgzthlnchlsyah> has quit IRC (Ping timeout: 258 seconds)[18:36:29] *** lieff[m] <lieff[m]!lieffmatri@gateway/shell/matrix.org/x-aibyyssftsbehugn> has quit IRC (Ping timeout: 276 seconds)[18:37:49] <exDM69> ville: is that a problem? it only affects the debug and allocation callbacks, right?[18:38:44] *** echotangoecho <echotangoecho!~echotango@dhcp-089-098-177-067.chello.nl> has joined ##vulkan[18:41:11] *** toor_ <toor_!~toor@76.ip-51-254-204.eu> has joined ##vulkan[18:47:53] *** afl_ext <afl_ext!~afl_ext3@unaffiliated/afl-ext/x-2796036> has quit IRC (Ping timeout: 252 seconds)[18:49:10] *** spossiba <spossiba!~spossiba@unaffiliated/stryx/x-3871776> has quit IRC (Ping timeout: 240 seconds)[18:51:28] *** spossiba <spossiba!~spossiba@unaffiliated/stryx/x-3871776> has joined ##vulkan[19:02:57] *** toor__ <toor__!~toor@76.ip-51-254-204.eu> has joined ##vulkan[19:03:12] *** toor_ <toor_!~toor@76.ip-51-254-204.eu> has quit IRC (Read error: Connection reset by peer)[19:05:54] *** Ralith_ <Ralith_!~ralith@c-24-143-67-131.customer.broadstripe.net> has quit IRC (Ping timeout: 240 seconds)[19:06:09] <ville> exDM69: it's a "problem". yes, it'd be more fun to parse if it was all nicely separated in xml tags. yes, it's parseable as is.[19:08:40] *** ector <ector!~asdf@37-247-11-157.customers.ownit.se> has joined ##vulkan[19:16:02] *** Ralith_ <Ralith_!~ralith@c-24-143-67-131.customer.broadstripe.net> has joined ##vulkan[19:21:21] *** LanDi <LanDi!~landi@191.33.11.30> has quit IRC (Remote host closed the connection)[19:22:50] *** jacres <jacres!~jacres@2607:f298:5:101d:f816:3eff:fe4e:182f> has joined ##vulkan[19:33:49] *** Feedz <Feedz!~Feedz@unaffiliated/feedz> has joined ##vulkan[19:34:13] *** nsf <nsf!~nsf@jiss.convex.ru> has quit IRC (Quit: WeeChat 1.7)[19:36:28] *** slidercrank <slidercrank!~slidercra@unaffiliated/slidercrank> has joined ##vulkan[19:55:26] *** afl_ext <afl_ext!~afl_ext3@bzi169.neoplus.adsl.tpnet.pl> has joined ##vulkan[19:55:26] *** afl_ext <afl_ext!~afl_ext3@bzi169.neoplus.adsl.tpnet.pl> has quit IRC (Changing host)[19:55:26] *** afl_ext <afl_ext!~afl_ext3@unaffiliated/afl-ext/x-2796036> has joined ##vulkan[20:01:58] *** slime <slime!~slime73@hlfxns016cw-142134041111.dhcp-dynamic.FibreOp.ns.bellaliant.net> has quit IRC (Quit: This computer has gone to sleep)[20:03:51] *** slime <slime!~slime73@hlfxns016cw-142134041111.dhcp-dynamic.FibreOp.ns.bellaliant.net> has joined ##vulkan[20:04:10] *** slime <slime!~slime73@hlfxns016cw-142134041111.dhcp-dynamic.FibreOp.ns.bellaliant.net> has quit IRC (Client Quit)[20:06:22] <Cheery> exDM69: I wondered a bit and I think I understand the pipeline barriers better now.. they weren't that hard concept after all.[20:08:02] <Cheery> https://github.com/cheery/lever/blob/master/samples/warpgpu/app0.lc[20:09:29] <Cheery> also I spot a common thread in what makes vulkan complex.[20:10:10] <Cheery> one thing is simply the large amount of prewired state.[20:10:25] <Cheery> another thing is the need to run stuff in batches.[20:12:06] <Cheery> it makes me think a partial evaluator -model of some kind would work.[20:15:03] *** kikijiki[m] <kikijiki[m]!kikijikima@gateway/shell/matrix.org/x-omwouusfriozguym> has joined ##vulkan[20:16:23] <jacres> what would cause the validation layers to stop working in a program? I remember them working well in the past for me, but I'm now able for example to exit my program without a clean shutdown/destruction and not getting any errors. I do get a lot of VK_DEBUG_REPORT_BIT_EXT messages, but nothing else seems to come through[20:16:45] <jacres> something I'm doing wrong, for sure. I'm using VK_LAYER_LUNARG_standard_validation[20:17:36] *** echotangoecho <echotangoecho!~echotango@dhcp-089-098-177-067.chello.nl> has quit IRC (Quit: leaving)[20:18:38] <jacres> so my callback seems to be called ok, and in the cbCreatInfo I'm specifying WARNING | PERF_WARNING | ERROR | DEBUG | INFO bits[20:20:02] *** afl_ext <afl_ext!~afl_ext3@unaffiliated/afl-ext/x-2796036> has quit IRC (Quit: Leaving)[20:21:02] *** ector <ector!~asdf@37-247-11-157.customers.ownit.se> has quit IRC ()[20:29:01] <jacres> ah found it[20:29:10] <Cheery> what was it?[20:30:20] <jacres> had refactored the code to separate out debugging and the validation layer was being enabled when creating the device, but not the instance[20:31:21] <ratchetfreak> device layers are ignored now IIRC[20:31:52] <jacres> ah would that be why it stopped working? this was from back in October[20:32:31] <jacres> or I may have never noticed after refactoring (just getting back to this codebase)[20:33:26] <Cheery> one thing. were you awaken by the webgpu announcement?[20:34:05] <jacres> me? you mean the reason I'm jumping back into this?[20:34:06] <derhass> awaken?[20:34:39] <Cheery> well for me it's a part reason why I'm looking back into my vulkan things today.[20:35:51] <Cheery> I think it validates the idea that there'll be a successfor for opengl which works in similar manner as vulkan.[20:36:21] <Cheery> it's also a problem description.. I think.[20:37:27] <Cheery> jacres: anyway. what's your reason?[20:37:47] <jacres> I've spent a number of years with GL and starting a new sandbox personal project where I need some good control over the rendering path. Have a prototype in GL, but using it as an excuse to work through vulkan. Aware that my shitty code may end up with worse perf than GL, but at least that's my fault and not the driver's ;)[20:39:02] <jacres> and a lot of CPU bound scenarios, so hopefully i'll see some benefit. Worst case it'll be some good learning[20:40:50] <jacres> for the type of work I normally do, vulkan won't give me much advantage in the eyes of clients as budgets don't normally allow for the extra time a vk path will take compared to GL. But I'm a sucker for going lower level[20:41:14] <Cheery> I'm looking into it to go higher level.[20:41:42] <ratchetfreak> but having something you can drop in as an extra "supports vulkan" for the marketing will help[20:42:22] <jacres> that's very true, it won't hurt![20:43:24] <ratchetfreak> and the more games have a requirement listing with opengl 4.*+ or vulkan 1.0 the more vulkan will gain traction[20:44:31] <ratchetfreak> especially when the vulkan path has more perf than the opengl path[20:45:39] *** ector <ector!~asdf@37-247-11-157.customers.ownit.se> has joined ##vulkan[20:45:47] <jacres> that's the thing. I was a bit let down by the initial presentations where perf was <= GL. But of course that's a combination of early drivers + patching vulkan into an older engine/renderer design[20:45:57] <Cheery> I've noticed so far that vulkan forms fairly pretty 'records' that I've managed to fill from json objects.[20:46:50] <ratchetfreak> and those where engines optimized for opengl with drivers optimized for the game[20:47:14] <jacres> that's true, dirty drivers ;)[20:47:22] <ratchetfreak> with vulkan you need to optimize on the game side heavily and apply all the hidden opt tricks opengl drivers will do[20:47:36] <jacres> think that will happen to vulkan drivers down the road (application patching?)[20:47:39] <derhass> well, not all of them[20:47:48] <jacres> to keep legacy things running[20:47:48] <derhass> drivers will do more dirty things than vulkan will allow you[20:49:23] <jacres> I guess shader patching would still be possible[20:52:30] <ratchetfreak> shader patching is the least of your problems[20:52:53] <ratchetfreak> things like vertex data sorting for cache optimization[20:53:36] <ratchetfreak> those are the kind of hidden opts drivers do[20:54:00] <jacres> Was reading about that.. insane how bloated the codebase must be[20:55:10] <Cheery> with some effort I can probably make it easy to form small renderers that do fairly simple specific things. But I wonder what help there should be for constructing large programs?[20:55:42] <Cheery> overall I've really never looked inside a complex big renderer.[20:55:59] *** bjz_ <bjz_!~bjz@104.222.140.127> has quit IRC (Ping timeout: 260 seconds)[20:56:02] <Cheery> or a game engine[20:56:07] *** bjz <bjz!~bjz@14-201-122-110.static.tpgi.com.au> has joined ##vulkan[20:56:20] <ratchetfreak> you will want to recognize a tonemapping pass and make that a different subpass[20:56:30] <jacres> Cheery: take a look at bgfx: https://github.com/bkaradzic/bgfx[20:56:41] <jacres> you can learn a lot from that codebarse[20:57:58] *** lpghatguy <lpghatguy!~LPGhatguy@63.153.99.104> has joined ##vulkan[20:58:28] <Cheery> ratchetfreak: that's interesting because I stumbled upon trying dithering on 24bit colorspace to extend it and thought it's kind of cool idea.[20:59:01] <jacres> ratchetfreak: is general rule for subpasses to use them for passes that don't require sampling neighbors (so tonemapping, gbuffer output, etc., but not things like blur/ssao/dof/bloom, etc)[20:59:02] <jacres> ?[20:59:50] <ratchetfreak> yeah you cannot (with the current set of extensions) get any neighbour fragments from the input attachment[21:00:48] <Cheery> jacres: https://github.com/cheery/lever/blob/master/samples/gl/glsl/1.frag#L47[21:00:59] <jacres> like you might do some reduction in compute to calc luminosity and then use that value as a push constant during a render pass that has a tonemapping subpass? (still wrapping my head around proper setup)[21:01:44] <Cheery> https://en.wikipedia.org/wiki/Ordered_dithering#/media/File:Ordered_4x4_Bayer_matrix_dithering.png[21:02:12] <Cheery> basically that but between 8-bit color bands.[21:02:59] <Cheery> doesn't need getting neighbour fragments[21:03:17] *** ZexaronS <ZexaronS!~zexpc@cpe-194-152-22-45.static.triera.net> has joined ##vulkan[21:03:57] *** bgrayburn[m] <bgrayburn[m]!bgrayburnm@gateway/shell/matrix.org/x-leqtlfdqglfvnetn> has joined ##vulkan[21:03:58] *** Wallbraker <Wallbraker!wallbraker@gateway/shell/matrix.org/x-jbyinjfswlicdrww> has joined ##vulkan[21:03:58] *** Ralith <Ralith!ralithrali@gateway/shell/matrix.org/x-cblaaivdvcpnzadj> has joined ##vulkan[21:03:58] *** atexborman[m] <atexborman[m]!atexborman@gateway/shell/matrix.org/x-fjzxyqlkyqoqrnsz> has joined ##vulkan[21:03:58] *** lieff[m] <lieff[m]!lieffmatri@gateway/shell/matrix.org/x-qiyvccslmpocjyle> has joined ##vulkan[21:03:58] *** karroffel <karroffel!karroffelm@gateway/shell/matrix.org/x-tfciyxkjmtbvfqgs> has joined ##vulkan[21:04:03] <Cheery> on a 4k display it works pretty much like extended colorspace. Though if they ever move to wider color channels it will look worse than without.[21:04:32] <Cheery> I didn't think you could treat that as a subpass.[21:04:47] <Cheery> if you can. it'd be sort of cool to flip it on and off.[21:06:29] <jacres> oh neat, what are you using it for?[21:07:07] <Cheery> for now I just drew some test images and checked how it compares.[21:07:56] <Cheery> the difference is subtle except with dark colors.[21:08:57] *** ravior <ravior!~crapitea@5-13-155-23.residential.rdsnet.ro> has joined ##vulkan[21:09:37] <derhass> optimally, you would take the nonlinearity into account during the dithering[21:10:43] <ratchetfreak> or add the dither in linear space and then tone map it[21:11:12] <derhass> ratchetfreak: yeah, but that would give you another in-between color values to dither[21:13:23] *** tambre <tambre!~tambre@1ad9-3c0f-7eab-c103-0e80-8a31-07d0-2001.dyn.estpak.ee> has quit IRC (Ping timeout: 258 seconds)[21:13:58] *** ector <ector!~asdf@37-247-11-157.customers.ownit.se> has quit IRC ()[21:16:14] *** LanDi <LanDi!~landi@191.33.11.30> has joined ##vulkan[21:20:01] *** slime <slime!~slime73@blk-215-81-93.eastlink.ca> has joined ##vulkan[21:25:56] *** Fats <Fats!~Fats@46.166.188.246> has quit IRC (Remote host closed the connection)[21:27:04] *** Fats <Fats!~Fats@46.166.190.140> has joined ##vulkan[21:32:03] *** w-t-h_ <w-t-h_!~chatzilla@72.67.52.110> has joined ##vulkan[21:42:01] *** nsf <nsf!~nsf@jiss.convex.ru> has joined ##vulkan[21:52:28] *** ZexaronS <ZexaronS!~zexpc@cpe-194-152-22-45.static.triera.net> has quit IRC (Quit: Leaving)[22:08:46] *** echotangoecho <echotangoecho!~echotango@dhcp-089-098-177-067.chello.nl> has joined ##vulkan[22:13:57] *** ShadowIce <ShadowIce!~pyoro@unaffiliated/shadowice-x841044> has quit IRC (Quit: Leaving)[22:16:05] *** lpghatguy <lpghatguy!~LPGhatguy@63.153.99.104> has quit IRC (Quit: I'll be back.)[22:27:46] *** sla_ro|master <sla_ro|master!~sla.ro@95.76.45.217> has quit IRC ()[22:41:21] *** bjz <bjz!~bjz@14-201-122-110.static.tpgi.com.au> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[22:45:00] *** LanDi <LanDi!~landi@191.33.11.30> has quit IRC (Remote host closed the connection)[22:45:14] *** bjz <bjz!~bjz@14-201-122-110.static.tpgi.com.au> has joined ##vulkan[22:50:59] *** Joefish <Joefish!~Joefish@p200300C6F3E8800097385718917CFA96.dip0.t-ipconnect.de> has joined ##vulkan[23:16:25] *** echotangoecho <echotangoecho!~echotango@dhcp-089-098-177-067.chello.nl> has quit IRC (Quit: leaving)[23:29:41] *** bjz <bjz!~bjz@14-201-122-110.static.tpgi.com.au> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[23:34:30] *** graphitemaster <graphitemaster!~graphitem@2604:a880:800:10::d8:c001> has quit IRC (Changing host)[23:34:30] *** graphitemaster <graphitemaster!~graphitem@unaffiliated/graphitemaster> has joined ##vulkan[23:34:59] *** Jackneill_ <Jackneill_!~Jackneill@unaffiliated/jackneill> has quit IRC (Remote host closed the connection)[23:37:16] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has quit IRC (Quit: Leaving)[23:39:26] *** nsf <nsf!~nsf@jiss.convex.ru> has quit IRC (Quit: WeeChat 1.7)[23:50:19] *** [xyzzy] <[xyzzy]!~xyzzy@2600:8803:e400:d600:21e:6ff:fecc:bedc> has quit IRC (Ping timeout: 255 seconds)[23:50:58] *** [xyzzy] <[xyzzy]!~xyzzy@2600:8803:e400:d600:21e:6ff:fecc:bedc> has joined ##vulkan