Switch to DuckDuckGo Search
   April 8, 2020
< | 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

Toggle Join/Part | bottom
[01:19:58] *** blackpawn <blackpawn!blackpawn@gateway/vpn/privateinternetaccess/blackpawn> has quit IRC (Quit: Leaving...)
[01:48:01] *** rardiol_ <rardiol_!~quassel@177.52.226.219> has joined ##vulkan
[01:49:22] *** rardiol <rardiol!~quassel@177.52.226.219> has quit IRC (Ping timeout: 258 seconds)
[01:52:34] *** mirv_ <mirv_!~mirv@xoreos/mirv> has quit IRC (Ping timeout: 240 seconds)
[02:05:57] *** mirv_ <mirv_!~mirv@xoreos/mirv> has joined ##vulkan
[02:11:34] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-82s3g7lnqmly2jqaqym.18120a2.ip6.access.telenet.be> has quit IRC (Quit: Leaving)
[02:14:20] *** ratchet_freak <ratchet_freak!~ratchetfr@ptr-82s3g7l9r42569r41f4.18120a2.ip6.access.telenet.be> has quit IRC (Ping timeout: 246 seconds)
[03:35:47] *** slime <slime!~slime73@host-24-138-72-158.public.eastlink.ca> has quit IRC (Quit: This computer has gone to sleep)
[03:36:23] *** LunarJetman <LunarJetman!LunarJetma@4e69e5a8.skybroadband.com> has left ##vulkan
[05:05:52] *** Andrej1 <Andrej1!~Andrej@BSN-143-213-124.dynamic.siol.net> has joined ##vulkan
[06:07:42] *** KDr21 <KDr21!~KDr2@1.85.217.27> has joined ##vulkan
[06:09:11] *** KDr2 <KDr2!~KDr2@1.85.216.126> has quit IRC (Ping timeout: 250 seconds)
[07:04:23] *** jfpoole <jfpoole!~textual@135-23-210-183.cpe.pppoe.ca> has joined ##vulkan
[07:14:06] *** soul-d <soul-d!~name@ip4da11736.direct-adsl.nl> has quit IRC (Remote host closed the connection)
[07:15:41] *** soul-d <soul-d!~uknown@2a02:a456:85ad:1:fc31:4127:2b55:b15c> has joined ##vulkan
[08:57:08] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-82s3g7ofgd8yey3pz4f.18120a2.ip6.access.telenet.be> has joined ##vulkan
[09:09:40] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has joined ##vulkan
[09:25:02] *** Lucretia <Lucretia!~Luke@pdpc/supporter/active/lucretia> has quit IRC (Quit: Konversation terminated!)
[09:29:02] *** Lucretia <Lucretia!~Luke@pdpc/supporter/active/lucretia> has joined ##vulkan
[10:18:01] *** shake <shake!~shake@cable-158-181-78-204.cust.telecolumbus.net> has quit IRC (Ping timeout: 265 seconds)
[11:16:38] *** Deluxe <Deluxe!~Deluxe@212.4.150.151> has joined ##vulkan
[11:43:31] *** shake <shake!~shake@195.243.102.188> has joined ##vulkan
[12:32:23] *** Lucretia <Lucretia!~Luke@pdpc/supporter/active/lucretia> has quit IRC (Quit: Konversation terminated!)
[12:33:59] *** rardiol_ <rardiol_!~quassel@177.52.226.219> has quit IRC (Ping timeout: 250 seconds)
[12:45:32] *** Lucretia <Lucretia!~Luke@pdpc/supporter/active/lucretia> has joined ##vulkan
[12:57:52] *** slime <slime!~slime73@host-24-138-72-158.public.eastlink.ca> has joined ##vulkan
[13:36:37] *** GoldenBear <GoldenBear!~gb@84.17.34.47> has quit IRC (Ping timeout: 256 seconds)
[13:37:50] *** GoldenBear <GoldenBear!~gb@84.17.53.169> has joined ##vulkan
[14:02:34] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has quit IRC (Quit: Leaving)
[14:02:54] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has joined ##vulkan
[16:23:03] *** wrobinson <wrobinson!~wrobinson@197.226.124.160> has joined ##vulkan
[16:23:26] <wrobinson> anyone know of a method on linux to generate a dependency graph for vulkan?
[16:23:45] <wrobinson> trying to visualise more clearly how things are connected - to help plan my project
[16:25:47] <wrobinson> maybe a dependency graph is not the way to go (seem to be focussed on includes only?)
[16:30:01] <turol> https://www.khronos.org/files/vulkan11-reference-guide.pdf
[16:30:05] <turol> https://gpuopen.com/v-ez-brings-easy-mode-vulkan/
[17:03:27] <wrobinson> thanks alot turol !
[17:11:55] <wrobinson> turol: am i right that a window has a vulkan instance?
[17:13:00] <turol> no, vulkan instance is global
[17:13:08] <turol> or you might have more than one instance maybe
[17:13:11] <turol> never tried that
[17:13:29] <turol> and you can in theory render to multiple windows (or no windows) from one instance
[17:13:35] <wrobinson> i would hope you wouldn't need more than one instance
[17:13:41] <wrobinson> ok cool
[17:14:40] <ratchetfreak> you need 1 swapchain per window you are rendering to
[17:16:50] <wrobinson> damn, swapchain not featured in the AMD visualisation
[17:16:53] <wrobinson> thanks ratchetfreak
[17:20:12] <wrobinson> right, so (in the case of glfw) glfw creates a surface in a vulkan instance, and displays it in a window
[17:22:05] <wrobinson> damn, would be nice to see how viewport, surface, swapchain, etc fit into something like this: https://gpuopen.com/wp-content/uploads/2018/03/Vulkan-API.png
[17:23:12] <ratchetfreak> swapchain has a set of images which you attach to the frambuffer
[17:23:33] <ratchetfreak> the swapchain is created from the vkSurface
[17:29:00] <wrobinson> thanks again - starting to build a better image in mind
[17:30:17] <wrobinson> multiple swapchains can use the same surface?
[17:30:36] <ratchetfreak> no, one active swapchain per surface
[17:30:54] <wrobinson> cool
[17:31:06] <ratchetfreak> you can "hand off" from one swapchain to a new one when the size changes
[17:31:21] <Yaniel> what do you mean "hand off"?
[17:32:49] <ratchetfreak> the oldSwapchain member in VkSwapchainCreateInfo
[17:38:01] <wrobinson> correct to say a window simply displays a surface then?
[17:39:05] <ratchetfreak> a window is whatever the windowing system thinks a window is, a vkSurface is the vulkan abstraction of a window
[17:45:26] <wrobinson> cool
[17:47:33] <wrobinson> and a surface can have multiple viewports?
[17:48:38] <Yaniel> multiple viewports is just a social construct
[17:48:49] <Yaniel> err I mean yes
[17:50:00] <wrobinson> :)
[17:54:05] *** rardiol <rardiol!~quassel@177.52.226.219> has joined ##vulkan
[17:57:19] <wrobinson> and a viewport shows an image from framebuffer (with swapchain storing framebuffers and images)?
[17:57:43] <wrobinson> "image" may not be appropriate term in this context...
[17:58:05] <Yaniel> no
[17:59:04] <Yaniel> viewport is just a subrect of a framebuffer that is used to determine where the normalized device coordinates map to
[17:59:46] <wrobinson> ah ok.
[18:00:39] <Yaniel> you also need a scissor rect to actually clip rendering to the viewport
[18:02:14] <wrobinson> which is normally the same dimensions as viewport?
[18:03:24] <Yaniel> of course
[18:04:17] <Yaniel> you can temporarily use a scissor rect smaller than the viewport for example to clip a scrolling list into a given border etc
[18:04:24] <Yaniel> while not having to change your coordinate transforms
[18:28:27] <wrobinson> makes sense
[18:29:28] <wrobinson> ratchetfreak: earlier you mentioned 1 swapchain per window
[18:29:46] <wrobinson> would it be more accurate to say one surface per window - which itself has one swapchain?
[18:30:28] <Yaniel> vulkan does not know anything about windows
[18:30:46] <Yaniel> it just gets a surface from the WSI and moves on
[18:31:13] <ratchetfreak> I said 1 *active* swapchain per window
[18:31:45] <wrobinson> per surface
[18:32:01] <ratchetfreak> but the earlier statement yeah one surface per window
[18:32:04] <wrobinson> Yaniel: fair point. was just trying to clarify earlier statement
[18:32:14] <ratchetfreak> and one active swapchain per surface
[18:32:19] <wrobinson> cool
[18:32:45] <wrobinson> i'm sure this is all pretty basic for you - i appreciate you takking the time to help me solidify this stuff in my head a bit
[18:36:54] *** ratchet_freak <ratchet_freak!~ratchetfr@ptr-82s3g7l9r42569r41f4.18120a2.ip6.access.telenet.be> has joined ##vulkan
[18:40:01] <wrobinson> a swapchain can hold many framebuffers - and a renderpass uses one of those framebuffers?
[18:40:36] <ratchet_freak> a swapchain holds several images
[18:40:59] <wrobinson> and is a renderpass separate from the swapchain - only really connected to a device?
[18:41:00] <ratchet_freak> those get attached to frambuffers
[18:43:03] <wrobinson> so it would be wrong to look at the framebuffer itself as a "child" of swapchain?
[18:43:19] <wrobinson> rather a separte, referenced entity?
[18:43:25] <wrobinson> separate*
[19:03:33] <wrobinson> maybe i shouldn't think in terms of parent and child (too object-oriented?) - or is it still reasonable to a certain extent?
[19:11:45] <Yaniel> too object-oriented I'd say
[19:13:18] <wrobinson> trying to shift my mindset to be more functional (appropriate term?)
[19:14:38] <wrobinson> using this also to help visualise: https://www.khronos.org/files/vulkan11-reference-guide.pdf
[19:15:24] <wrobinson> but then i see something like VkCommandBufferAllocateInfo has struct with a VkCommandPool
[19:15:45] <wrobinson> even though not marked, would i be right in saying that CommandPool is a pointer/reference?
[19:16:26] <Yaniel> pretty sure it's an opaque handle
[19:20:06] <wrobinson> synonymous with opaque pointer?
[19:20:40] <turol> not quite
[19:20:44] <turol> pointer is machine sized
[19:20:50] <turol> opaque handle not necessarily
[19:21:17] <turol> the only thing you're allowed to do with it is to pass to appropriate vulkan calls
[19:21:56] <wrobinson> ah - damn I still have so much to learn
[19:22:59] *** LunarJetman <LunarJetman!LunarJetma@4e69e5a8.skybroadband.com> has joined ##vulkan
[19:23:09] <wrobinson> is it bad to think of them as pointers conceptually? (i'm guessing yes - need to embed opaque handle into my brain)
[19:28:20] <Yaniel> well it's wrong
[19:28:46] <Yaniel> but idk about bad
[19:29:45] <wrobinson> when searching for "opaque handle" i only seem to find info on opaque pointers
[19:29:58] <wrobinson> is opaque handle a C/CPP term?
[19:30:48] <wrobinson> "only" was a bit wrong - looking more like mostly
[19:37:32] <wrobinson> ratchet_freak: seems I've found relevent comments from you to an issue regarding opaque handles on SO :) (https://softwareengineering.stackexchange.com/a/294764)
[20:11:15] <Yaniel> opaque just means that you can't know anything about it
[20:11:17] <Yaniel> it's a thing
[20:11:20] <Yaniel> you get it from a function
[20:11:25] <Yaniel> you give it to another function of the same API
[20:11:55] <Yaniel> it's just black box that identifies some resource
[20:12:45] <wrobinson> thanks - reading around, getting a better picture
[20:12:52] <Yaniel> the API implementation is use whatever it wants as the handle, you just aren't told about it and you can't rely on it staying the same or even following any pattern
[20:14:31] <Yaniel> staying the same as in getting the same handle across program runs
[20:17:26] <wrobinson> so as long as the handle is to something you cannot manipulate other than via the API, this should be fine, as all "business" is taken care of by the API
[20:17:27] <wrobinson> ?
[20:18:23] <Yaniel> yes
[20:18:51] <Yaniel> that's usually the point of using an opaque handle to begin with
[20:26:27] <wrobinson> cool cheers
[20:30:40] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has quit IRC (Quit: Leaving)
[20:32:58] *** haagch <haagch!~quassel@frickel.club> has quit IRC (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
[20:33:53] *** haagch <haagch!~quassel@frickel.club> has joined ##vulkan
[20:41:02] *** shake <shake!~shake@195.243.102.188> has quit IRC (Ping timeout: 265 seconds)
top

   April 8, 2020
< | 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