May 1, 2018 
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | >
May 1, 2018 [00:07:02] *** jdashg <jdashg!~jdashg@corp-nat.fw1.untrust.mtv2.mozilla.net> has joined ##vulkan[00:20:30] *** Deluxe <Deluxe!~Deluxe@212.4.150.151> has quit IRC (Remote host closed the connection)[00:20:54] *** Deluxe_ <Deluxe_!~Deluxe@212.4.150.151> has quit IRC (Remote host closed the connection)[00:33:33] *** random_james is now known as random_james_awy[00:38:58] *** echotangoecho <echotangoecho!~echotango@92-108-127-60.cable.dynamic.v4.ziggo.nl> has quit IRC (Quit: Lost terminal)[00:54:57] *** borkr <borkr!~borkr@static130-244.mimer.net> has quit IRC (Ping timeout: 240 seconds)[00:54:58] *** Defcronyke <Defcronyke!~Defcronyk@cryptospread.com> has quit IRC (Ping timeout: 264 seconds)[00:59:27] *** Defcronyke <Defcronyke!~Defcronyk@cryptospread.com> has joined ##vulkan[01:01:43] *** Fats <Fats!fats@gateway/vpn/privateinternetaccess/fats> has quit IRC (Quit: WeeChat 2.0.1)[01:02:01] *** glYoda <glYoda!~MTLYoda@c-73-25-27-206.hsd1.or.comcast.net> has quit IRC (Quit: glYoda)[01:32:24] *** MrFlibble <MrFlibble!MrFlibble@2.221.166.255> has left ##vulkan[01:50:39] *** Kingsquee <Kingsquee!~kingsquee@d108-180-233-73.bchsia.telus.net> has quit IRC (Remote host closed the connection)[02:23:41] *** robot-beethoven <robot-beethoven!~robot-bee@c-24-118-208-243.hsd1.mn.comcast.net> has joined ##vulkan[02:34:27] *** jdashg <jdashg!~jdashg@corp-nat.fw1.untrust.mtv2.mozilla.net> has quit IRC (Ping timeout: 240 seconds)[03:11:53] *** hlmjr <hlmjr!~herb@c-76-120-173-141.hsd1.pa.comcast.net> has joined ##vulkan[03:14:49] <jophish> Why is the pNext member in VkDebugUtilsMessengerCallbackDataEXT optional?[03:14:55] <jophish> when most other are not optional[03:15:03] <jophish> (although I think they should be optional in the spec)[03:22:20] <jophish> Also: Is it the case that if a struct is an extension of another struct which is returnedonly then the extending struct is returnedonly?[03:31:45] *** tarceri <tarceri!~tarceri@101.176.49.19> has quit IRC (Ping timeout: 248 seconds)[03:33:16] *** Fats <Fats!fats@gateway/vpn/privateinternetaccess/fats> has joined ##vulkan[03:50:38] *** daxar1 <daxar1!~daxar@194-118-46-175.adsl.highway.telekom.at> has joined ##vulkan[03:51:10] *** Guest20702 <Guest20702!~james@static-96-43-65-242.albyny.csvoip.net> has quit IRC (Quit: Leaving)[03:53:27] *** daxar <daxar!~daxar@194-96-56-184.adsl.highway.telekom.at> has quit IRC (Ping timeout: 240 seconds)[04:02:04] *** cheakoirccloud <cheakoirccloud!uid293319@gateway/web/irccloud.com/x-xuziihnijgrnraet> has quit IRC (Quit: Connection closed for inactivity)[04:06:07] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-82s3g7lnh68c25ewjdd.18120a2.ip6.access.telenet.be> has quit IRC (Ping timeout: 256 seconds)[04:07:47] *** cheakoirccloud <cheakoirccloud!uid293319@gateway/web/irccloud.com/x-tesujfzhofmvregd> has joined ##vulkan[04:31:32] *** slime <slime!~slime73@blk-215-81-93.eastlink.ca> has quit IRC (Quit: This computer has gone to sleep)[04:34:03] *** xaxazak <xaxazak!~xaxazak@125-237-144-101-fibre.bb.spark.co.nz> has joined ##vulkan[04:34:26] *** tarceri <tarceri!~tarceri@101.176.49.19> has joined ##vulkan[05:24:39] *** Stenzek <Stenzek!~stenzek@2001:19f0:5801:3fe:5400:ff:fe5d:7bf6> has joined ##vulkan[05:37:56] *** tarceri <tarceri!~tarceri@101.176.49.19> has quit IRC (Read error: Connection reset by peer)[05:38:13] *** tarceri <tarceri!~tarceri@101.176.49.19> has joined ##vulkan[05:53:12] *** Kingsquee <Kingsquee!~kingsquee@d108-180-233-73.bchsia.telus.net> has joined ##vulkan[06:22:50] *** xissburg <xissburg!~xissburg@unaffiliated/xissburg> has quit IRC (Quit: ZZZzzz…)[06:56:40] *** glYoda <glYoda!~MTLYoda@c-73-25-27-206.hsd1.or.comcast.net> has joined ##vulkan[07:20:07] *** xaxazak <xaxazak!~xaxazak@125-237-144-101-fibre.bb.spark.co.nz> has quit IRC (Quit: Leaving.)[07:26:16] *** Pseudocrat <Pseudocrat!~quassel@cpe-76-183-103-244.tx.res.rr.com> has joined ##vulkan[07:26:16] *** Pseudocrat <Pseudocrat!~quassel@cpe-76-183-103-244.tx.res.rr.com> has quit IRC (Changing host)[07:26:16] *** Pseudocrat <Pseudocrat!~quassel@unaffiliated/pseudocrat> has joined ##vulkan[07:26:37] *** davr0s <davr0s!~textual@host81-155-68-228.range81-155.btcentralplus.com> has joined ##vulkan[07:42:04] *** cheakoirccloud <cheakoirccloud!uid293319@gateway/web/irccloud.com/x-tesujfzhofmvregd> has quit IRC (Quit: Connection closed for inactivity)[07:43:57] *** d3x0r <d3x0r!~d3x0r@ip174-72-226-164.lv.lv.cox.net> has quit IRC (Read error: Connection reset by peer)[08:05:39] *** sla_ro|master <sla_ro|master!~sla.ro@78.96.209.89> has joined ##vulkan[09:44:02] *** ville_ <ville_!~ville@37-136-53-74.rev.dnainternet.fi> has joined ##vulkan[09:46:32] *** ville <ville!~ville@87-95-86-146.bb.dnainternet.fi> has quit IRC (Ping timeout: 268 seconds)[09:46:34] *** ville_ is now known as ville[09:48:23] *** davr0s <davr0s!~textual@host81-155-68-228.range81-155.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[09:58:00] *** Sairon <Sairon!~Sairon@185.57.104.138> has joined ##vulkan[10:16:10] *** xaxazak <xaxazak!~xaxazak@125-237-144-101-fibre.bb.spark.co.nz> has joined ##vulkan[10:47:18] *** Kingsquee <Kingsquee!~kingsquee@d108-180-233-73.bchsia.telus.net> has quit IRC (Quit: Just Monica.)[10:47:53] *** MrCooper <MrCooper!~MrCooper@2a02:120b:c3ce:9910:3a63:bbff:feca:3701> has quit IRC (Ping timeout: 256 seconds)[11:02:11] *** davr0s <davr0s!~textual@host81-155-68-228.range81-155.btcentralplus.com> has joined ##vulkan[11:10:37] *** nsf <nsf!~nsf@jiss.convex.ru> has joined ##vulkan[11:14:01] *** davr0s <davr0s!~textual@host81-155-68-228.range81-155.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[11:21:25] *** MrCooper <MrCooper!~MrCooper@2a02:120b:c3ce:9910:3a63:bbff:feca:3701> has joined ##vulkan[11:53:47] *** robot-beethoven <robot-beethoven!~robot-bee@c-24-118-208-243.hsd1.mn.comcast.net> has quit IRC (Quit: leaving)[11:57:44] *** thany <thany!~thany@5.134.164.23> has joined ##vulkan[12:14:38] *** stqn <stqn!~stqn@pdc38-1-82-246-180-56.fbx.proxad.net> has joined ##vulkan[12:23:16] <stqn> Hi, the doc on layers at https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/blob/master/loader/LoaderAndLayerInterface.md says you have to implement vkNegotiateLoaderLayerInterfaceVersion , but the official layer example does not… https://github.com/LunarG/VulkanSamples/tree/master/Layer-Samples So I guess it’s not needed after all?[12:24:20] <baldurk> the loader/layer interface has grown, vkNegotiateLoaderLayerInterfaceVersion is recommended for new layers but there was an old path that didn't use it[12:30:45] <stqn> ok, if I do anything it will be the old way then, thanks.[12:32:31] <baldurk> FWIW I implemented it yesterday, it's not super complicated, but yeh you can get by with the old way for now[12:36:21] *** davr0s <davr0s!~textual@host81-155-68-228.range81-155.btcentralplus.com> has joined ##vulkan[12:36:36] *** xaxazak <xaxazak!~xaxazak@125-237-144-101-fibre.bb.spark.co.nz> has quit IRC (Quit: Leaving.)[12:39:36] <stqn> yeah… I was just hoping to be able to copy-paste a simple example layer as much as possible to do mine.[12:40:25] *** xaxazak <xaxazak!~xaxazak@125-237-144-101-fibre.bb.spark.co.nz> has joined ##vulkan[12:42:10] *** xaxazak <xaxazak!~xaxazak@125-237-144-101-fibre.bb.spark.co.nz> has quit IRC (Client Quit)[12:44:10] *** xaxazak <xaxazak!~xaxazak@125-237-144-101-fibre.bb.spark.co.nz> has joined ##vulkan[12:52:22] <stqn> ah, I see you wrote https://renderdoc.org/vulkan-layer-guide.html , I was reading that and I switched to the official doc since you recommended it :)[12:53:30] <stqn> (but it’s long)[12:53:42] <turol> lunarg has the factory layer which is supposed to make creating layers easier[12:53:47] <turol> have you looked at it?[12:54:17] <stqn> hm no[13:00:17] <baldurk> yeh the spec is the spec, just like the vulkan spec people should use it as a reference. I wrote that as a more digestible explanation of how things work[13:02:32] *** slime <slime!~slime73@blk-215-81-93.eastlink.ca> has joined ##vulkan[13:19:24] *** slime <slime!~slime73@blk-215-81-93.eastlink.ca> has quit IRC (Quit: This computer has gone to sleep)[13:20:39] *** davr0s <davr0s!~textual@host81-155-68-228.range81-155.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[13:20:58] *** Deluxe <Deluxe!~Deluxe@212.4.150.151> has joined ##vulkan[13:40:17] *** bpmedley <bpmedley!~bpm@c-24-72-144-115.ni.gigamonster.net> has quit IRC (Ping timeout: 248 seconds)[13:40:31] *** thany <thany!~thany@5.134.164.23> has quit IRC (Ping timeout: 256 seconds)[13:50:47] *** bpmedley <bpmedley!~bpm@c-24-72-144-115.ni.gigamonster.net> has joined ##vulkan[13:51:15] *** psychicist__ <psychicist__!~psychicis@wlan-145-94-157-135.wlan.tudelft.nl> has joined ##vulkan[13:56:19] *** thany <thany!~thany@188.75.83.82> has joined ##vulkan[14:14:47] *** thany <thany!~thany@188.75.83.82> has quit IRC (Ping timeout: 268 seconds)[14:24:31] *** davr0s <davr0s!~textual@host81-155-68-228.range81-155.btcentralplus.com> has joined ##vulkan[14:29:56] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-82s3g7lnh68c25ewjdd.18120a2.ip6.access.telenet.be> has joined ##vulkan[15:31:29] *** s_20 <s_20!~simon@xinutec.org> has joined ##vulkan[15:35:14] *** davr0s <davr0s!~textual@host81-155-68-228.range81-155.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[15:39:05] *** psychicist__ <psychicist__!~psychicis@wlan-145-94-157-135.wlan.tudelft.nl> has quit IRC (Ping timeout: 240 seconds)[16:04:57] *** james <james!~james@static-96-43-65-242.albyny.csvoip.net> has joined ##vulkan[16:05:21] *** james is now known as Guest82858[16:24:52] *** Deluxe <Deluxe!~Deluxe@212.4.150.151> has quit IRC (Read error: Connection reset by peer)[16:25:58] *** Deluxe <Deluxe!~Deluxe@212.4.150.151> has joined ##vulkan[16:40:17] *** james_ <james_!~james@static-96-43-65-242.albyny.csvoip.net> has joined ##vulkan[16:41:17] *** Guest82858 <Guest82858!~james@static-96-43-65-242.albyny.csvoip.net> has quit IRC (Ping timeout: 256 seconds)[17:06:57] *** baldurk <baldurk!~baldurk@104.171.115.98> has quit IRC (Ping timeout: 264 seconds)[17:07:05] *** baldurk <baldurk!~baldurk@104.171.115.98> has joined ##vulkan[17:10:04] *** cheakoirccloud <cheakoirccloud!uid293319@gateway/web/irccloud.com/x-ywaasgyvkqqebgxh> has joined ##vulkan[17:14:09] *** xissburg <xissburg!~xissburg@unaffiliated/xissburg> has joined ##vulkan[17:33:03] *** sharpnel1 <sharpnel1!sharpneli@hilla.kapsi.fi> has quit IRC (Ping timeout: 256 seconds)[17:33:10] *** sharpneli <sharpneli!sharpneli@hilla.kapsi.fi> has joined ##vulkan[17:34:05] *** haagch <haagch!~quassel@2a03:4000:2:4e6::dead:beef> has quit IRC (Read error: Connection reset by peer)[17:34:31] *** haagch <haagch!~quassel@mx.frickel.club> has joined ##vulkan[17:34:45] *** Lucretia <Lucretia!~laguest@pdpc/supporter/active/lucretia> has quit IRC (Read error: Connection reset by peer)[17:37:17] *** Lucretia <Lucretia!~laguest@2a02:c7d:3c35:b000:325a:3aff:fe0f:37a5> has joined ##vulkan[17:37:17] *** Lucretia <Lucretia!~laguest@2a02:c7d:3c35:b000:325a:3aff:fe0f:37a5> has quit IRC (Changing host)[17:37:17] *** Lucretia <Lucretia!~laguest@pdpc/supporter/active/lucretia> has joined ##vulkan[18:11:14] *** random_james_awy is now known as random_james[18:14:35] *** glYoda <glYoda!~MTLYoda@c-73-25-27-206.hsd1.or.comcast.net> has quit IRC (Quit: glYoda)[18:15:31] *** glYoda <glYoda!~MTLYoda@c-73-25-27-206.hsd1.or.comcast.net> has joined ##vulkan[18:25:25] *** davr0s <davr0s!~textual@host81-155-68-228.range81-155.btcentralplus.com> has joined ##vulkan[19:28:41] *** Defcronyke <Defcronyke!~Defcronyk@cryptospread.com> has quit IRC (Quit: Goodbye)[19:29:14] *** Defcronyke <Defcronyke!~Defcronyk@cryptospread.com> has joined ##vulkan[19:41:16] *** MrFlibble <MrFlibble!MrFlibble@2.221.166.255> has joined ##vulkan[19:42:52] *** davr0s <davr0s!~textual@host81-155-68-228.range81-155.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[19:48:43] *** james <james!~james@static-96-43-65-242.albyny.csvoip.net> has joined ##vulkan[19:49:06] *** james is now known as Guest36192[19:50:26] *** james_ <james_!~james@static-96-43-65-242.albyny.csvoip.net> has quit IRC (Ping timeout: 276 seconds)[19:50:30] *** Biolunar <Biolunar!Biolunar@p5B14859F.dip0.t-ipconnect.de> has joined ##vulkan[19:52:57] *** Guest36192 <Guest36192!~james@static-96-43-65-242.albyny.csvoip.net> has quit IRC (Ping timeout: 240 seconds)[19:53:11] *** james_ <james_!~james@static-96-43-65-242.albyny.csvoip.net> has joined ##vulkan[19:59:54] *** hlmjr <hlmjr!~herb@c-76-120-173-141.hsd1.pa.comcast.net> has quit IRC (Remote host closed the connection)[20:03:08] *** psychicist__ <psychicist__!~psychicis@5356A22B.cm-6-7c.dynamic.ziggo.nl> has joined ##vulkan[20:19:53] *** nsf <nsf!~nsf@jiss.convex.ru> has quit IRC (Quit: WeeChat 2.0.1)[20:37:50] *** Kingsquee <Kingsquee!~kingsquee@d108-180-233-73.bchsia.telus.net> has joined ##vulkan[20:59:02] *** Zexaron <Zexaron!~zex-pc@cpe-86-58-122-93.static.triera.net> has joined ##vulkan[21:12:17] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has joined ##vulkan[21:27:45] *** MrFlibble <MrFlibble!MrFlibble@2.221.166.255> has left ##vulkan[21:31:39] <mefesto> taking a small step at a time. i have a basic single threaded case working well and wanted to expand this test app into multiple threads. for a single graphics queue, is having a thread pool where each thread builds a secondary command pool up, while the main render thread waits and when they are all in, main thread submits to the queue for each subpass a reasonable approach? better approach?[21:32:30] <mefesto> err, secondary commands -> primary command buffer -> one submit to queue[21:47:57] <chrisf> they neednt even be secondary buffers.[21:52:56] <mefesto> ah good to know[22:02:24] *** jdashg <jdashg!~jdashg@corp-nat.fw1.untrust.mtv2.mozilla.net> has joined ##vulkan[22:07:05] *** jdashg <jdashg!~jdashg@corp-nat.fw1.untrust.mtv2.mozilla.net> has quit IRC (Ping timeout: 240 seconds)[22:08:05] *** soulz <soulz!~soulz@unaffiliated/soulz> has quit IRC (Quit: leaving)[22:09:28] *** sla_ro|master <sla_ro|master!~sla.ro@78.96.209.89> has quit IRC ()[22:15:22] <chrisf> mefesto: absolutely, preparing command buffers on multiple threads is sane[22:17:25] *** soulz <soulz!~soulz@unaffiliated/soulz> has joined ##vulkan[22:17:56] *** jdashg <jdashg!~jdashg@corp-nat.fw1.untrust.mtv2.mozilla.net> has joined ##vulkan[22:19:33] *** davr0s <davr0s!~textual@host81-155-64-238.range81-155.btcentralplus.com> has joined ##vulkan[22:25:57] <mefesto> so when submitting to the queue from the main thread (after the other threads have finished their work), the main thread would submit command buffers such as: (cbuffer that starts render pass), (worker 1 cbuffer), (worker 2 cbuffer), (worker n cbuffer), (cbuffer that ends render pass)...?[22:28:02] <zeromuisan> if you were lucky or clever you could arrange for earlier ones to finish sooner, and submit as soon as the next required one arrives[22:29:12] *** davr0s <davr0s!~textual@host81-155-64-238.range81-155.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[22:29:52] <zeromuisan> main thread can be: launch N tasks; for each task in order do wait for task; submit task; end;[22:30:51] <mefesto> an area of confusion for me is that the command buffers don't share state. i'm guessing beginning a render pass isn't what is meant by "state"?[22:31:49] <mefesto> like if you were to bind a pipeline, that only affects that particular command buffer... not separate subsequent command buffers... so each must explicitly bind a pipeline. atleast that's how i understand it[22:32:08] <zeromuisan> its only confusing because youre undoing something confusing. whats left is simple[22:32:08] *** davr0s <davr0s!~textual@host81-155-64-238.range81-155.btcentralplus.com> has joined ##vulkan[22:32:53] <zeromuisan> im pretty sure anyway. ive just used other vulkan-like apis that arent vulkan. what you just described sounds right[22:33:28] <zeromuisan> i mean, if you happen to know all the commandbuffers depend on some state thats the same, then you could put it only in the 1st one you executed[22:34:08] <zeromuisan> its supposed to be nothing but a batch of commands. no redundant commands are going to get executed unless you tell them to. thats the whole point of organizing things this way: it's all in your hands and you can make sure NOTHING redundant happens[22:34:49] <baldurk> zeromuisan: state is not inherited between command buffers, so you can't leave a pipeline bound from one into another even if you know it's the same[22:35:04] <mefesto> This section clears it up some... i'll need to let it sink in[22:35:10] <mefesto> https://www.khronos.org/registry/vulkan/specs/1.0-wsi_extensions/html/vkspec.html#commandbuffers[22:35:24] <mefesto> "Each command buffer manages state independently of other command buffers. There is no inheritance of state across primary and secondary command buffers, or between secondary command buffers. When a command buffer begins recording, all state in that command buffer is undefined. When secondary command buffer(s) are recorded to execute on a primary command buffer, the secondary command buffer inherits no state from the primary command[22:35:24] <mefesto> buffer, and all state of the primary command buffer is undefined after an execute secondary command buffer command is recorded."[22:35:48] <zeromuisan> ok, thats weird. does the command buffer have a memory of what pipeline is bound so that it can check for mistakes? seems like a waste of effort.,..[22:35:48] <mefesto> going over the exception portion regarding render pass / subpass.[22:35:49] *** davr0s <davr0s!~textual@host81-155-64-238.range81-155.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[22:38:08] <zeromuisan> what you pasted just seems like its clearing up arbitrary misconceptions that are just confused carryovers from older times. can "undefined" state mean "whatever it was last set to?" or can vulkan say "error, this is undefined, and you accidentally depended on it"[22:38:34] <ratchetfreak> the validation layers will say error[22:39:13] <zeromuisan> simultaneously lame and awesome. i suspect i would turn off that layer.[22:39:27] <baldurk> then your code would crash and you'd have to figure out by hand why[22:39:37] <zeromuisan> im fine with that. my code will run fast after it's debugged.[22:39:41] <mefesto> hmm really not understanding this part, "There is one exception to this rule - if the primary command buffer is inside a render pass instance, then the render pass and subpass state is not disturbed by executing secondary command buffers."[22:39:59] <baldurk> that's the idea of the validation layers, turn them on during development and ship with them disabled[22:40:53] <zeromuisan> that particular kind of validation would be frustrating to deal with during development, as i'd be de-optimizing things just to pacify its checking of dependent state. i mean, i guess there wouldnt be much validation left if i turned that part off.[22:40:54] <mefesto> so if a primary cbuffer is in a render pass instance, it's state isn't "disturbed" by secondary cbuffers?[22:40:58] <zeromuisan> sorry for interrupting your questions, mefesto[22:41:06] <mefesto> no worries[22:41:53] <ratchetfreak> but the validation layer doesn't pipe up until you would have done something invalid according to the api[22:41:57] <baldurk> zeromuisan: I'm not sure I understand, the validation layers would check that in a command buffer you have a valid pipeline bound. It's not de-optimizing to bind a pipeline, you *must*. There's no circumstance where a pipeline from a previous primary command buffer could be used in a subsequent primary command buffer[22:42:20] <ratchetfreak> after which the implementation is allowed to UB and summon a group of demons in your nostrils[22:43:44] <zeromuisan> i dont know what primary and secondary commandbuffers are. i only know what commandbuffers are from other apis. in that case, the commandbuffers dont know or care what pipeline is set. if i depend on what was previously set, that's my business. to be clear, i have no idea what vulkan does in detail, im just using this as an excuse to learn[22:44:13] <ratchetfreak> primary command buffers can be submitted directly for execution[22:44:20] *** borkr <borkr!~borkr@static130-244.mimer.net> has joined ##vulkan[22:44:32] <ratchetfreak> secondary are submitted to a primary buffer for execution[22:45:43] <zeromuisan> are there differences in what commands they receive? or are they two tiers of virtually the same thing?[22:46:24] <ratchetfreak> everything you can do in a secondary you can do in a primary[22:46:36] <mefesto> my take is that they are the same thing with a well defined rule about their independence... no state leaks[22:46:48] <ratchetfreak> but in a secondary you cannot or start or end a renderpass (or go to next subpass)[22:47:12] <mefesto> ratchetfreak: ahh i think you just answered my prior question[22:47:42] <ratchetfreak> there are a few other limitations but I can't think of the off the top of my head[22:48:35] <mefesto> if one were to split up work for a given subpass, then secondary cbuffers are the main way to do that, right?[22:48:52] <chrisf> yes[22:50:11] <mefesto> okay i think im beginning to get it[22:50:34] <chrisf> a renderpass is fully contained within one primary CB.[22:52:06] <mefesto> so if submitting multiple *primary* CBs, each one is doing it's own render pass?[22:52:48] <ratchetfreak> yeah, renderpasses cannot cross primary command buffers[22:53:28] <mefesto> cool, i think the fog in my brain is lifting[23:01:38] *** xaxazak <xaxazak!~xaxazak@125-237-144-101-fibre.bb.spark.co.nz> has quit IRC (Quit: Leaving.)[23:04:13] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has quit IRC (Quit: Leaving)[23:05:02] * chrisf rolls eyes at earlier discussion of UB-for-speed[23:11:08] *** Deluxe <Deluxe!~Deluxe@212.4.150.151> has quit IRC (Remote host closed the connection)[23:18:24] *** psychicist__ <psychicist__!~psychicis@5356A22B.cm-6-7c.dynamic.ziggo.nl> has quit IRC (Ping timeout: 256 seconds)[23:23:57] *** borkr <borkr!~borkr@static130-244.mimer.net> has quit IRC (Ping timeout: 240 seconds)[23:25:28] *** slime <slime!~slime73@blk-215-81-93.eastlink.ca> has joined ##vulkan[23:28:09] <Ralith> rendering exactly the frame you want is one possible outcome of UB, therefore deref null and pray :D[23:28:56] *** rotaerk <rotaerk!rotaerk@2600:3c02::f03c:91ff:fe70:4a45> has quit IRC (Ping timeout: 245 seconds)[23:30:49] *** stqn <stqn!~stqn@pdc38-1-82-246-180-56.fbx.proxad.net> has left ##vulkan[23:37:42] *** Biolunar <Biolunar!Biolunar@p5B14859F.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 255 seconds)[23:42:35] *** rotaerk <rotaerk!~rotaerk@ender.afternet.org> has joined ##vulkan[23:47:43] *** mandeep <mandeep!mandeep@gateway/vpn/privateinternetaccess/mandeepb> has quit IRC (Quit: Leaving)[23:57:22] *** MrFlibble <MrFlibble!MrFlibble@2.221.166.255> has joined ##vulkan