June 16, 2018 
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | >
June 16, 2018 [00:15:11] *** Quetzal2 <Quetzal2!~Quetzal2@unaffiliated/quetzal2> has quit IRC (Quit: ?? Bye!)[00:15:54] *** Deluxe <Deluxe!~Deluxe@212.4.150.151> has quit IRC (Remote host closed the connection)[00:16:17] *** Deluxe <Deluxe!~Deluxe@212.4.150.151> has joined ##vulkan[00:18:09] *** Guest4630 <Guest4630!4d3b9548@gateway/web/cgi-irc/kiwiirc.com/ip.77.59.149.72> has quit IRC (Ping timeout: 260 seconds)[00:29:29] *** Fats <Fats!fats@gateway/vpn/privateinternetaccess/fats> has quit IRC (Remote host closed the connection)[00:30:42] *** Fats <Fats!fats@gateway/vpn/privateinternetaccess/fats> has joined ##vulkan[00:31:05] <dyl> fkaa undefined behavior?[00:50:01] *** nsf <nsf!~nsf@jiss.convex.ru> has quit IRC (Quit: WeeChat 2.1)[01:26:08] <lpg> do the validation layers catch it?[01:47:31] *** random_james is now known as random_james_awy[01:53:02] *** ciaala <ciaala!~crypt@2a02:120b:2c1f:4960:6ef0:49ff:feee:4777> has quit IRC (Quit: Konversation terminated!)[02:00:39] *** Deluxe <Deluxe!~Deluxe@212.4.150.151> has quit IRC (Read error: Connection reset by peer)[03:02:09] <Shockk> chrisf: I had another quick question about SPIR-V; I noticed that the SPIR-V generated from glslang declares the Shader capability, but I also notice that ity uses OpAccessChain even though the SPIR-V spec seems to imply that OpAccessChain is only valid when the Kernel capability has been declared[03:03:00] <chrisf> Shockk, OpAccessChain does not require any capabilities[03:04:00] <Shockk> oooooh wait, the section I was reading was referring specifically to using OpAcccessChain as an opcode to OpSpecConstantOp lol[03:04:20] <Shockk> I just didn't read above where I ctrl-f'd[03:06:46] <Shockk> is there any reason why, in the case where OpAccessChain is being used with what's essentially gl_Position, I shouldn't just use OpInBoundsAccessChain here? i.e. I imagine the instruction can be better optimized if it's assumed to be in-bounds, but I don't know if that can cause unforeseen issues[03:06:48] <chrisf> fkaa, the behavior is as if you sampled from the source and[03:07:03] <chrisf> fkaa, wrote out via an attachment write[03:11:33] <chrisf> Shockk, you could, if you can guarantee the condition[03:11:46] <Shockk> okay[03:12:31] <Shockk> I assume my computer may potentially become skynet (undefined behaviour) if I can't[03:47:38] *** cheakoirccloud <cheakoirccloud!uid293319@gateway/web/irccloud.com/x-gdjbjunrlbswjphx> has quit IRC (Quit: Connection closed for inactivity)[04:14:30] *** Water` <Water`!~Water___@unaffiliated/water/x-6277176> has quit IRC (Quit: Water`)[04:29:32] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-82s3g7lgupdkti53lhr.18120a2.ip6.access.telenet.be> has quit IRC (Ping timeout: 255 seconds)[04:32:31] *** MrFlibble2 <MrFlibble2!MrFlibble@2.122.47.217> has quit IRC (Ping timeout: 268 seconds)[06:36:18] *** slime <slime!~slime73@blk-215-81-93.eastlink.ca> has quit IRC (Quit: This computer has gone to sleep)[06:44:06] *** xissburg <xissburg!~xissburg@unaffiliated/xissburg> has quit IRC (Quit: leaving)[06:45:28] *** xissburg <xissburg!~xissburg@unaffiliated/xissburg> has joined ##vulkan[07:15:51] *** davr0s <davr0s!~textual@host86-153-157-230.range86-153.btcentralplus.com> has joined ##vulkan[07:38:10] *** mandeep <mandeep!mandeep@gateway/vpn/privateinternetaccess/mandeepb> has joined ##vulkan[08:13:49] *** ciaala <ciaala!~crypt@2a02:120b:2c1f:4960:6ef0:49ff:feee:4777> has joined ##vulkan[08:24:32] *** nsf <nsf!~nsf@jiss.convex.ru> has joined ##vulkan[09:04:50] *** nsf <nsf!~nsf@jiss.convex.ru> has quit IRC (Quit: WeeChat 2.1)[09:15:50] *** kasumi-owari <kasumi-owari!~kasumi-ow@ftth-213-233-237-007.solcon.nl> has quit IRC (Ping timeout: 265 seconds)[09:16:42] *** kasumi-owari <kasumi-owari!~kasumi-ow@ftth-213-233-237-007.solcon.nl> has joined ##vulkan[09:19:27] *** xissburg <xissburg!~xissburg@unaffiliated/xissburg> has quit IRC (Quit: ZZZzzz…)[09:23:08] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has joined ##vulkan[09:29:53] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has quit IRC (Ping timeout: 276 seconds)[09:33:19] *** Guest4630 <Guest4630!4d3b9548@gateway/web/cgi-irc/kiwiirc.com/ip.77.59.149.72> has joined ##vulkan[09:40:33] *** ville <ville!~ville@37-33-15-143.bb.dnainternet.fi> has quit IRC (Quit: Lost terminal)[10:00:59] *** ville <ville!~ville@37-33-15-143.bb.dnainternet.fi> has joined ##vulkan[10:06:44] *** borkr <borkr!~borkr@static130-244.mimer.net> has joined ##vulkan[10:10:23] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has joined ##vulkan[10:11:35] *** ciaala <ciaala!~crypt@2a02:120b:2c1f:4960:6ef0:49ff:feee:4777> has quit IRC (Quit: Konversation terminated!)[10:51:27] *** Deluxe <Deluxe!~Deluxe@212.4.150.151> has joined ##vulkan[10:53:08] *** ector <ector!~asdf@ua-85-224-236-175.bbcust.telenor.se> has joined ##vulkan[11:05:06] *** neurre <neurre!~tsuoranta@193.209.96.43> has joined ##vulkan[11:07:59] <neurre> does spriv-opt do constant propagation?[12:10:41] *** davr0s <davr0s!~textual@host86-153-157-230.range86-153.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[12:10:45] *** psychicist__ <psychicist__!~psychicis@5356A22B.cm-6-7c.dynamic.ziggo.nl> has joined ##vulkan[12:20:52] *** mandeep_ <mandeep_!~mandeep@unaffiliated/mandeepb> has joined ##vulkan[12:23:27] *** mandeep <mandeep!mandeep@gateway/vpn/privateinternetaccess/mandeepb> has quit IRC (Ping timeout: 240 seconds)[12:30:58] *** Deluxe <Deluxe!~Deluxe@212.4.150.151> has quit IRC (Remote host closed the connection)[12:55:20] *** MrFlibble <MrFlibble!MrFlibble2@2.122.47.217> has joined ##vulkan[13:11:30] *** penguin42 <penguin42!~dg@cpc109017-salf6-2-0-cust428.10-2.cable.virginm.net> has joined ##vulkan[13:17:52] *** Deluxe <Deluxe!~Deluxe@212.4.150.151> has joined ##vulkan[13:29:23] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-82s3g7lgupdkti53lhr.18120a2.ip6.access.telenet.be> has joined ##vulkan[13:29:25] *** davr0s <davr0s!~textual@host86-153-157-230.range86-153.btcentralplus.com> has joined ##vulkan[13:31:25] *** nsf <nsf!~nsf@jiss.convex.ru> has joined ##vulkan[13:44:23] *** Deluxe_ <Deluxe_!~Deluxe@212.4.150.151> has joined ##vulkan[14:05:55] *** Deluxe_ <Deluxe_!~Deluxe@212.4.150.151> has quit IRC (Read error: Connection reset by peer)[14:19:33] *** borkr <borkr!~borkr@static130-244.mimer.net> has quit IRC (Ping timeout: 256 seconds)[14:30:35] *** ector <ector!~asdf@ua-85-224-236-175.bbcust.telenor.se> has quit IRC (Ping timeout: 240 seconds)[14:45:04] *** Deluxe_ <Deluxe_!~Deluxe@212.4.150.151> has joined ##vulkan[15:44:38] *** Deluxe <Deluxe!~Deluxe@212.4.150.151> has quit IRC (Remote host closed the connection)[15:48:25] *** Deluxe <Deluxe!~Deluxe@212.4.150.151> has joined ##vulkan[15:48:50] *** Deluxe <Deluxe!~Deluxe@212.4.150.151> has quit IRC (Remote host closed the connection)[16:02:31] *** ector <ector!~asdf@ua-85-224-236-175.bbcust.telenor.se> has joined ##vulkan[16:06:19] *** davr0s <davr0s!~textual@host86-153-157-230.range86-153.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[16:22:33] *** Guest4630 <Guest4630!4d3b9548@gateway/web/cgi-irc/kiwiirc.com/ip.77.59.149.72> has quit IRC (Ping timeout: 264 seconds)[16:33:55] *** slime <slime!~slime73@24.215.81.93> has joined ##vulkan[16:34:17] *** Guest4630 <Guest4630!4d3b9548@gateway/web/cgi-irc/kiwiirc.com/ip.77.59.149.72> has joined ##vulkan[16:36:37] *** Guest4630 <Guest4630!4d3b9548@gateway/web/cgi-irc/kiwiirc.com/ip.77.59.149.72> has quit IRC (Client Quit)[16:37:21] *** davr0s <davr0s!~textual@host86-153-157-230.range86-153.btcentralplus.com> has joined ##vulkan[16:49:38] *** Guest4630 <Guest4630!4d3b9548@gateway/web/cgi-irc/kiwiirc.com/ip.77.59.149.72> has joined ##vulkan[17:54:36] *** xissburg <xissburg!~xissburg@unaffiliated/xissburg> has joined ##vulkan[17:55:35] *** ector <ector!~asdf@ua-85-224-236-175.bbcust.telenor.se> has quit IRC (Ping timeout: 276 seconds)[18:20:13] *** nsf <nsf!~nsf@jiss.convex.ru> has quit IRC (Quit: WeeChat 2.1)[18:22:24] *** sla_ro|master <sla_ro|master!~sla.ro@78.96.209.89> has joined ##vulkan[18:53:00] *** cramalho <cramalho!~cramalho@2804:54:16f5:8200:bd67:9a34:7fbd:ea22> has joined ##vulkan[19:26:06] *** salek_ <salek_!~salek@91-155-9-229.elisa-laajakaista.fi> has joined ##vulkan[19:26:27] *** Salek <Salek!~salek@91-155-9-229.elisa-laajakaista.fi> has quit IRC (Ping timeout: 240 seconds)[19:30:27] *** cramalho <cramalho!~cramalho@2804:54:16f5:8200:bd67:9a34:7fbd:ea22> has quit IRC (Quit: cramalho)[19:30:55] *** cramalho <cramalho!~cramalho@2804:54:16f5:8200:bd67:9a34:7fbd:ea22> has joined ##vulkan[19:42:12] *** ishan_ <ishan_!~ishan@2405:205:221e:9bfc:7ece:c9c2:d785:d2fd> has joined ##vulkan[20:05:52] <friden> I'm trying to fill multiple command buffers from separate threads, and then submit them from one thread after all worker threads have been completed[20:06:07] <friden> if i only use one worker threads, it all works[20:06:33] <friden> but if i use two worker threads, and submits both command buffers to vkQueueSubmit, only the first one is showing up[20:06:51] <ratchetfreak> how many pools do you have[20:06:52] <friden> im setting the pCommandBuffers, and commandBufferCount in the VkSubmitInfo[20:06:54] <friden> two pools[20:06:59] <ratchetfreak> one for each thread?[20:07:03] <friden> N pols[20:07:07] <friden> yeah, one for each thread[20:07:18] <friden> and the command buffers for each thread is from its own pool[20:07:31] <friden> didn't do that from the start but got a nice warning about that in the validation layers[20:08:02] <friden> i only have one wait semaphore, and one signal semaphore though[20:08:09] <friden> do i need to have one for each commandbuffer?[20:08:17] <friden> i though they were per submit[20:08:42] <ratchetfreak> you updated the count field in the submit info?[20:09:05] <friden> yeah, commandBufferCount is the same number as the number of threads[20:09:10] <friden> which has one command buffer each[20:10:30] <friden> basically each thread is adding a push constant and then a draw command[20:10:38] <friden> a few hundred times[20:10:57] <friden> but i must be missing something[20:11:08] <friden> the exact same code running for one worker displays all triangles[20:11:17] <friden> 2 workers display exactly the first half[20:17:53] <friden> ratchetfreak: here is a snippet of the submit and present if you see anything obvious: https://pastebin.com/EezCtQxW[20:19:44] <ratchetfreak> and the command buffers are complete enders and have barriers so they wait on each other?[20:19:48] <ratchetfreak> *renders[20:20:18] <turol> are you using the same renderpass for both command buffers?[20:20:38] <turol> does it clear the render targets at start?[20:20:56] <friden> ratchetfreak: yeah, they have fences before aquiring new images[20:21:05] *** merzbow <merzbow!~merzbow@rrcs-64-183-56-162.west.biz.rr.com> has joined ##vulkan[20:21:49] <friden> turol: no im using one renderpass per command buffer[20:21:57] <friden> can they share render pass?[20:22:05] <turol> no, i'm talking about the renderpass object itself[20:22:11] <turol> of course you have two instances of that pass[20:22:13] <turol> one per buffer[20:22:28] <turol> but it's possible you're effectively doing "clear, render, clear, render"[20:22:35] <turol> so of course only half of the stuff is showing up[20:23:16] <turol> if you want to start only one renderpass instance you need secondary buffers[20:23:32] <turol> fill secondaries on workers, then main starts render pass and puts both secondaries in there[20:23:57] <friden> i am doing clear from the "main thread" before posting jobs to sub threads that only do bindBipeline, bindVertexBuffers, bindIndexBuffers, bindDescriptorSets, then (cmdPushConstans, cmdDrawIndexed) in loop[20:24:18] <friden> and then endRenderpass, endComamnd buffer per thread[20:24:34] <turol> and the code which creates your renderpass?[20:24:55] <turol> load up renderdoc and make sure the submitted command buffers are doing what you think they are doing[20:25:02] <friden> each thread begins a renderpass, should i let the main thread do that instead?[20:26:44] <turol> only after you understand the difference between primary and secondary command buffers and what they're allowed and not allowed to do[20:26:57] <friden> yeah, i need to read up on that part[20:27:08] <turol> for now, show the code which creates your renderpass[20:27:14] <turol> the problem is probably there[20:27:16] <friden> the work committed from "background threads" are secondary command buffers?[20:27:21] <turol> no[20:27:33] <turol> you only submit primary buffers[20:27:46] <turol> secondary buffers are put in primary buffers before execution[20:28:00] <turol> if i remember this right, i've only read the spec, not actually used them[20:28:23] <friden> this is the whole code for each background thread: https://pastebin.com/jn5HYDBD[20:29:10] <friden> this is from the main thread: https://pastebin.com/vwxd5Tq7[20:29:28] *** neurre <neurre!~tsuoranta@193.209.96.43> has quit IRC (Quit: Leaving)[20:29:47] <turol> that's still not the code which CREATES the renderpass[20:29:58] <turol> but this:[20:30:00] <turol> renderPassInfo.pClearValues = &clearColor;[20:30:11] <turol> seems to indicate that the problem is exactly what i guessed[20:30:50] <friden> ah[20:30:53] <friden> now i see what you mean[20:31:25] <friden> i should have no clear value for all but first command buffer executed[20:31:53] <turol> not sufficient, you need two different renderpasses[20:32:04] <turol> first one specifies clear[20:32:07] <turol> the second one keep[20:32:25] <ratchetfreak> and make sure you submit the clear one first[20:32:25] <turol> and after you get that working move to using secondary command buffers[20:32:38] *** nsf <nsf!~nsf@jiss.convex.ru> has joined ##vulkan[20:33:14] <friden> yeah, the submitorder is already established, but i see now that i begun each command buffer with a clear, lol[20:37:10] *** cocholate_ <cocholate_!~cppfag@187.67.9.46> has quit IRC (Ping timeout: 260 seconds)[20:38:40] <friden> i just got a bit confused[20:38:52] <friden> now i see that i have to create more than one render pass[20:38:56] <friden> one with LOAD_OP_CLEAR[20:39:02] <friden> which should obviously clear[20:39:21] *** Guest4630 <Guest4630!4d3b9548@gateway/web/cgi-irc/kiwiirc.com/ip.77.59.149.72> has quit IRC (Remote host closed the connection)[20:39:23] <friden> and a second one with LOAD, which will preserve the previous content[20:39:33] <friden> do i need to ccreate a framebuffer for each render pass?[20:39:40] <friden> or can they share framebuffer?[20:40:36] <friden> seems like i need one for each, since we set the renderpass in the framebuffer create info?[20:41:00] <ratchetfreak> but the clear is independent of the frambuffer object[20:41:37] <friden> so i only need one framebuffer, for the LOAD renderpass?[20:42:10] <ratchetfreak> load and clear can use the same renderpass[20:42:26] <ratchetfreak> *s/renderpass/framebuffer/[20:43:11] <friden> but when i tried to set the clearValueCount, i got the following error:[20:43:15] <friden> "In vkCmdBeginRenderPass() the VkRenderPassBeginInfo struct has a clearValueCount of 0 but there must be at least 1 entries in pClearValues array to account for the highest index attachment in renderPass 0xb that uses VK_ATTACHMENT_LOAD_OP_CLEAR is 1"[20:43:22] <friden> which suggests i need more renderpasses?[20:43:32] <ratchetfreak> yeah you need 2 renderpasses[20:43:37] <friden> *when i tried to set it to 0 for all but the first[20:43:37] <ratchetfreak> one with clear and one with load[20:43:44] <ratchetfreak> I misstyped there[20:43:53] <friden> and i let the background threads generate render commands to the one with load[20:44:02] <friden> and clear on the first one with CLEAR set?[20:44:47] <friden> so... same question about the framebuffers again[20:45:03] <friden> one framebuffer for the clear renderpass, and one for the load?[20:48:01] <ratchetfreak> one framebuffer for both[20:48:45] <friden> but when i create the framebuffer, the creation info requires a framebuffer... which should use?[20:48:56] <friden> *requires a render pass[20:49:07] <friden> should i use the clear render pass, or load render pass?[20:49:21] <ratchetfreak> either, they shohuld be compatible[20:49:53] <friden> ok, thanks for the help![20:50:44] <friden> oh, the pipelinecreateinfo also requires a renderpass, same thing here?[20:50:50] <friden> can i use either clear or load renderpass?[20:51:41] <friden> i mean, the clear don't need shaders and stuff, so i use the load one?[20:52:08] <turol> you can use one renderpass for creating the framebuffer and pipeline[20:52:14] <turol> but they must be *compatible*[20:52:21] <turol> look in the spec for definition of compatible renderpasses[20:52:31] <turol> basically the same number and format of attachments[20:55:20] <friden> yeah, but lets say they are compatible, and i have two of them. one with the CLEAR load op set, and one with the LOAD op set. can i use the CLEAR renderpass to create both the framebuffer and pipeline with?[20:55:54] <turol> yes[20:55:58] <friden> i don't really see the purpose of setting a renderpass to a framebuffer or a pipeline?[20:56:11] <friden> if it doesn't matter which i choose?[20:56:22] <turol> it matters[20:56:31] <turol> because you're only allowed to use compatible renderpasses[20:56:46] <turol> the driver does stuff at pipeline creation time which needs to know render attachment formats[20:57:36] <friden> ah ok, and as long as they contain the same formats, it won't matter for me which renderpass the drivers get the formats from[20:57:37] <ratchetfreak> and the attachments are refered to by number which is the index they are declared in in the renderpass[20:59:13] <friden> ok, i think i have what i need. ill create two render passes, one with clear and one with load. i will still have one framebuffer and one pipeline, created from the clear renderpass. both renderpasses should be compatible. i use the clear renderpass to clear from the main thread, and the load renderpass to fill from the background threads[20:59:35] <friden> and i make sure to submit the commandbuffer with the clear before the ones with load[21:01:50] <ratchetfreak> if the clear renderpass is going to be empty you may as well do a normal vkCmdClearColorImage and vkCmdClearDepthStencilImage in that first command buffer[21:02:22] <friden> and your saying that now? :P now i have created 2 render passes lol[21:02:36] <friden> ok, ill do that instead[21:02:44] <ratchetfreak> because I thought one of the threads was going to get the clear renderpass to fill[21:02:49] <turol> or have one thread use the clear renderpass and the other(s) load render pass[21:02:56] <turol> and main thread not doing a renderpass at all[21:03:01] <ratchetfreak> ^[21:03:08] <turol> explicit clear is less efficient than using renderpasses[21:03:16] <turol> also layout transitions get tricky[21:03:18] <friden> the good thing about having the separate render pass is that the main thread can generate the clear while the sub threads are generating draw calls[21:03:51] <friden> i may have a bunch of resources to clear later, might as well be good to have a separate renderpass for it?[21:04:30] <turol> you want to clear resources when you first start using them[21:04:40] <turol> otherwise the gpu might pull them into memory uselessly[21:04:45] <turol> more of a problem on mobile[21:04:57] <friden> ah, good to know[21:05:07] <friden> the first background thread will use the clear renderpass then[21:09:39] *** davr0s <davr0s!~textual@host86-153-157-230.range86-153.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[21:22:09] *** cramalho <cramalho!~cramalho@2804:54:16f5:8200:bd67:9a34:7fbd:ea22> has quit IRC (Remote host closed the connection)[21:24:38] <friden> cool, everything seems to be working now, thanks![21:29:01] *** cramalho <cramalho!~cramalho@179.190.254.211> has joined ##vulkan[21:29:20] *** nsf <nsf!~nsf@jiss.convex.ru> has quit IRC (Quit: WeeChat 2.1)[21:33:51] *** ishan_ <ishan_!~ishan@2405:205:221e:9bfc:7ece:c9c2:d785:d2fd> has quit IRC (Remote host closed the connection)[21:39:30] <friden> i profiled a bit after successfully using multiple threads to generate the draw commands, but notices things were actually running slower than before[21:39:40] <friden> https://imgur.com/a/h3HTouQ[21:40:09] <ratchetfreak> well yeah 2 renderpasses is going to be slower than a single one[21:40:42] <friden> yeah, but even the background threads generating the 3 other command buffers are slower[21:40:54] <friden> this is just the cpu side, generating the commands[21:41:46] <turol> use a cpu-counter sampling profiler to see what's going on[21:41:49] <friden> i've tried eleminating the glm framework by just pushing an identity matrix also, but the cmdpushconstants and cmddrawindexed is taking longer when multiple threads are calling them[21:41:54] <friden> than if one is calling them[21:41:55] <turol> you might have false sharing or other cache problems[21:42:27] <friden> ok, hang on[21:42:58] <ratchetfreak> and turn off the validation layers as well[21:43:03] <ratchetfreak> they might be syncing on you[21:43:56] <friden> ok, a profile using cpu sampling WITH valudation layers say 47% of time on cdarIndexed and 44% on pushconstants[21:44:04] <friden> ill try disabling the validation layers[21:46:40] <friden> hooly shit, up from 280 fps to 5000[21:47:10] <ratchetfreak> thought so[21:47:30] <ratchetfreak> don't to timing measurements when there is logging or debugging on your critical loop[21:48:01] <friden> yeah, i didn't think the validation layers would mess with timing[21:48:28] <friden> i would want them to validate the same timing that my shipped application runs...[21:51:04] <baldurk> the validation layers are full of global locks because they use map lookups for data, but even if they didn't they'll always have a decent overhead that will invalidate any profiling[21:51:52] <friden> yeah[21:52:03] <friden> anyways, now things are looking as expected: https://imgur.com/a/Z104rKg[21:52:05] <friden> thanks for the help![21:52:15] <ratchetfreak> it's technically possible to not need to lock like that when doing lookups but that tends to be bug prone[21:52:38] <ratchetfreak> especially when you want to catch invalid synchronization[21:52:45] *** davr0s <davr0s!~textual@host86-153-157-230.range86-153.btcentralplus.com> has joined ##vulkan[22:00:07] *** cramalho <cramalho!~cramalho@179.190.254.211> has quit IRC (Quit: cramalho)[22:01:17] *** merzbow <merzbow!~merzbow@rrcs-64-183-56-162.west.biz.rr.com> has quit IRC (Ping timeout: 276 seconds)[22:33:28] * penguin42 is using a compute shader to calculate pixels in an image, and I suddenly wondered - should it be a compute shader?[22:33:58] <penguin42> it doesn't feel like it's vertex/geometry/fragment though - so perhaps compute is the right thign?[22:34:48] <ratchetfreak> you can do a fullscreen quad/triangle if you can express the shader like you would in shadertoy[22:35:19] <penguin42> is there any advantage to that over a compute shader ?[22:35:36] <ratchetfreak> the renderpass will be better suited to fill the image[22:37:31] <penguin42> can you point me at anything that would explain why?[22:38:35] <ratchetfreak> I know of at least one set of hardware that uses separate hardware for compute and fragment shading[22:38:43] <ratchetfreak> though that's a mobile gpu[22:38:56] <penguin42> that's....a curious choice[22:38:58] <ratchetfreak> https://community.arm.com/graphics/b/blog/posts/using-compute-post-processing-in-vulkan-on-mali[22:39:14] <ratchetfreak> well separate as in different cores on the same die[22:39:56] <ratchetfreak> and fragment has a few special operations that are only used in fragment shaders[22:40:20] <ratchetfreak> and it's often the bottleneck to dedicating a lot of hardware to it and offloading everything else isn't stupid[22:40:28] <penguin42> oh, so it's (vertex+tiling+compute) + fragement - that's not as odd[22:41:23] <ratchetfreak> keep in mind that article is only about that hardware[22:41:35] <ratchetfreak> other gpus would have different performance characteristis[22:42:05] <penguin42> nod[22:43:22] <penguin42> in my case it's a ray tracer tay tracing a voxel set (that I calculated once using a compute shader, but it's not recalculated on each frame)[22:57:54] <fazias> if you can make use of compute shaders advantages to get speedups.[22:58:18] <fazias> if you don't use shared memory or subgroup stuff, maybe it should be pixel shader.[23:00:29] <penguin42> when you say pixel shader; is that the same as a fragment shader or separate?[23:01:13] <fazias> fragment shader yeah[23:01:24] <ratchetfreak> pixel shader is microsoft speak for fragment shader[23:01:28] <fazias> gah, forgot the name of a access pattern...[23:02:53] <penguin42> fazias: Thanks; adds that to his list of things to learn to figure out[23:04:57] *** nsf <nsf!~nsf@jiss.convex.ru> has joined ##vulkan[23:11:45] <fazias> also to add[23:11:49] <fazias> https://en.wikipedia.org/wiki/Z-order_curve[23:12:04] <fazias> might be better access pattern than just going row by row[23:16:42] *** Water` <Water`!~Water___@2607:fea8:5ba0:1957:4de:44b1:6d80:7548> has joined ##vulkan[23:16:51] *** Water` <Water`!~Water___@2607:fea8:5ba0:1957:4de:44b1:6d80:7548> has quit IRC (Changing host)[23:16:51] *** Water` <Water`!~Water___@unaffiliated/water/x-6277176> has joined ##vulkan[23:19:34] *** sla_ro|master <sla_ro|master!~sla.ro@78.96.209.89> has quit IRC ()[23:22:08] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has quit IRC (Quit: Leaving)[23:27:50] *** MrFlibble <MrFlibble!MrFlibble2@2.122.47.217> has quit IRC (Ping timeout: 256 seconds)[23:43:45] *** psychicist__ <psychicist__!~psychicis@5356A22B.cm-6-7c.dynamic.ziggo.nl> has quit IRC (Quit: Lost terminal)