Switch to DuckDuckGo Search
   January 31, 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 | 29 | 30 | 31 | >

Toggle Join/Part | bottom
[00:00:52] <mike__> nice, just what i was looking for
[00:01:01] <mike__> thanks all
[00:03:52] *** HuntsMan <HuntsMan!~hunts@cpc104822-sgyl39-2-0-cust136.18-2.cable.virginm.net> has joined ##vulkan
[00:05:09] *** zgreg <zgreg!~greg@nest-1.gnumpf.tk> has quit IRC (Disconnected by services)
[00:05:09] *** zgreg_ <zgreg_!~greg@nest-1.gnumpf.tk> has joined ##vulkan
[00:05:10] *** zgreg_ is now known as zgreg
[00:08:18] *** ShaneC <ShaneC!~shane@rrcs-69-75-6-186.west.biz.rr.com> has quit IRC (Read error: Connection reset by peer)
[00:44:20] *** ShaneC <ShaneC!~shane@rrcs-69-75-6-186.west.biz.rr.com> has joined ##vulkan
[00:48:09] *** toor_ <toor_!~toor@76.ip-51-254-204.eu> has quit IRC (Remote host closed the connection)
[01:09:48] *** user0501829 <user0501829!~liveuser@47-184-237-79.dlls.tx.frontiernet.net> has joined ##vulkan
[01:12:20] *** user0501829 <user0501829!~liveuser@47-184-237-79.dlls.tx.frontiernet.net> has quit IRC (Quit: Leaving)
[01:19:40] *** derhass <derhass!~derhass@ipservice-092-216-126-046.092.216.pools.vodafone-ip.de> has quit IRC (Quit: leaving)
[01:27:59] *** Kingsquee <Kingsquee!~kingsley@d206-116-126-21.bchsia.telus.net> has joined ##vulkan
[01:40:53] *** David3k <David3k!~David3k@130.105.229.127> has joined ##vulkan
[01:48:21] *** David3k <David3k!~David3k@130.105.229.127> has quit IRC (Ping timeout: 255 seconds)
[02:14:55] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-82s3g7l9r42569r41f4.18120a2.ip6.access.telenet.be> has quit IRC (Ping timeout: 255 seconds)
[02:15:14] *** salamanderrake <salamanderrake!~quassel@2605:a000:1229:c036:60a2:7de6:eb1c:8ec7> has quit IRC (Remote host closed the connection)
[02:16:10] *** salamanderrake <salamanderrake!~quassel@2605:a000:1229:c036:8c0:35ea:d04d:8c70> has joined ##vulkan
[02:16:41] *** doomlord <doomlord!~textual@host86-148-102-241.range86-148.btcentralplus.com> has joined ##vulkan
[02:19:51] *** C-Man <C-Man!~Coldberg@78-56-219-19.static.zebra.lt> has quit IRC (Ping timeout: 245 seconds)
[02:26:42] *** doomlord <doomlord!~textual@host86-148-102-241.range86-148.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[02:31:52] *** doomlord <doomlord!~textual@host86-148-102-241.range86-148.btcentralplus.com> has joined ##vulkan
[02:41:34] *** glYoda <glYoda!~MTLYoda@c-71-236-230-251.hsd1.or.comcast.net> has quit IRC (Quit: glYoda)
[02:41:36] *** mike__ <mike__!32e9580a@gateway/web/freenode/ip.50.233.88.10> has quit IRC (Quit: Page closed)
[03:02:41] *** neurre <neurre!~tsuorant@a91-155-31-190.elisa-laajakaista.fi> has joined ##vulkan
[03:03:54] *** john1 <john1!~john@host86-143-93-17.range86-143.btcentralplus.com> has quit IRC (Ping timeout: 258 seconds)
[03:04:47] *** neurrre <neurrre!~tsuorant@a91-155-31-190.elisa-laajakaista.fi> has quit IRC (Ping timeout: 276 seconds)
[03:06:43] *** drasich <drasich!~indefini@124x35x243x164.ap124.ftth.ucom.ne.jp> has joined ##vulkan
[03:11:00] *** doomlord <doomlord!~textual@host86-148-102-241.range86-148.btcentralplus.com> has quit IRC (Read error: Connection reset by peer)
[03:24:12] *** GMpow2_2 <GMpow2_2!~5@2a02:810a:83c0:cb14:3572:efde:4d2a:315c> has joined ##vulkan
[03:27:22] *** GMpow2 <GMpow2!~5@2a02:810a:83c0:cb14:3572:efde:4d2a:315c> has quit IRC (Ping timeout: 255 seconds)
[03:35:28] *** GMpow2_2 <GMpow2_2!~5@2a02:810a:83c0:cb14:3572:efde:4d2a:315c> has quit IRC (Ping timeout: 240 seconds)
[03:40:30] *** _28_ria <_28_ria!~igoryonya@194.226.6.106> has quit IRC (Read error: Connection reset by peer)
[03:42:04] *** _28_ria <_28_ria!~igoryonya@194.226.6.106> has joined ##vulkan
[03:53:29] *** tarceri <tarceri!~tarceri@CPE-120-144-40-53.lnse5.win.bigpond.net.au> has quit IRC (Read error: No route to host)
[03:54:58] *** _28_ria <_28_ria!~igoryonya@194.226.6.106> has quit IRC (Read error: Connection reset by peer)
[03:56:26] *** _28_ria <_28_ria!~igoryonya@194.226.6.106> has joined ##vulkan
[04:06:17] *** lpghatguy <lpghatguy!~LPGhatguy@63.153.99.104> has joined ##vulkan
[04:31:46] *** GMpow5srV <GMpow5srV!~goedelmac@55d46471.access.ecotel.net> has joined ##vulkan
[04:35:43] *** ShaneC <ShaneC!~shane@rrcs-69-75-6-186.west.biz.rr.com> has quit IRC (Quit: Leaving.)
[04:35:47] *** GMpow3srV <GMpow3srV!~goedelmac@55d44171.access.ecotel.net> has quit IRC (Ping timeout: 276 seconds)
[04:39:23] *** glYoda <glYoda!~MTLYoda@c-71-236-230-251.hsd1.or.comcast.net> has joined ##vulkan
[04:41:53] *** nicebyte <nicebyte!~nicebyte@216-243-5-35.users.condointernet.net> has joined ##vulkan
[04:53:03] <nicebyte> Hello!
[04:53:10] <nicebyte> I'm trying to get a grasp of Vulkan by writing a simple single-threaded renderer that just renders a bunch of given models with some diffuse textures applied.
[04:53:15] <nicebyte> I need some help understanding how to properly use descriptor sets....
[04:53:25] <nicebyte> Basically I want to have a single descriptor pool, and on each frame, allocate one set per model from it, and update it with model-specific data (i.e. uniform buffer with matrices, image sampler), and later bind that set when recording the command buffer.
[04:53:33] <nicebyte> But I'm not sure how to go about deallocating those descriptor sets (they have to remain alive as long as the referencing command buffer is in flight) and what to do when the pool runs out of descriptor sets...
[04:53:38] <nicebyte> Any tips?
[04:53:54] <chrisf> nicebyte: tie them to a fence.
[04:55:18] <chrisf> nicebyte: if your pool actually runs out, you have two strategies: prove that something is no longer in use and reclaim it; or allocate another pool
[05:05:29] <nicebyte> @chrisf trying to think how to go about this w/o introducing any stalls... In addition to allocating a new pool when the existing one runs out, I'm imagining having possibly having multiple fences, allocating a new one every time we allocate a new bunch of descriptor sets. Then we keep track of all fences and their associated allocations, every now and then we check on fences and return the associated descriptor sets to the pool
[05:05:29] <nicebyte> if the a fence is signaled. Is my thinking correct?
[05:14:48] *** xissburg <xissburg!~xissburg@unaffiliated/xissburg> has quit IRC (Ping timeout: 240 seconds)
[05:15:52] *** xissburg <xissburg!~xissburg@unaffiliated/xissburg> has joined ##vulkan
[05:22:12] *** lpghatguy <lpghatguy!~LPGhatguy@63.153.99.104> has quit IRC (Read error: Connection reset by peer)
[05:28:33] <chrisf> nicebyte: yes
[05:28:51] <chrisf> that granularity could be as coarse as 'end of each frame'
[05:29:17] <chrisf> and you just size things to 2-3 frames worth
[05:30:10] <chrisf> re avoiding stalls -- it's not actually in your interest to have a /huge/ queue of pending work. you just dont want the gpu to run out.
[05:31:06] <chrisf> one entire frame is tons.
[05:31:57] *** ravior <ravior!~crapitea@86.122.215.14> has quit IRC (Quit: Konversation terminated!)
[05:33:41] *** slime <slime!~slime73@blk-215-81-93.eastlink.ca> has quit IRC (Ping timeout: 240 seconds)
[05:33:54] <chrisf> nicebyte: one approach which may give you pretty minimal overhead would be to have a ring of pools
[05:34:12] <chrisf> bump to the next pool when you start a new frame
[05:34:28] <chrisf> and you can then recover all the descriptor sets for a previous frame with no micromanagement by resetting its pool
[05:35:03] *** slime <slime!~slime73@blk-215-81-93.eastlink.ca> has joined ##vulkan
[05:35:34] <nicebyte> @chrisf and once the pools run out, worst case is i'll have to wait a bit
[05:36:19] <chrisf> which isnt bad -- you've run ahead as far as you'd ever want to in that case
[05:36:49] <nicebyte> @chrisf I think I understand now, thanks a lot for the help
[05:42:11] <nicebyte> unrelated - is it reasonable to have one uniform buffer with matrices per object? what's the tradeoff between using uniform buffers vs push constants?
[05:45:48] <chrisf> is going to depend on the driver
[05:47:26] <chrisf> push constants ought to be a bit faster to read on most hw, but the space is very very limited -- the minmax is only 128 bytes (2 mat4s)
[05:50:37] <chrisf> so if you're doing 1 object per draw, and you have nothing else that really needs that space, go for it
[05:50:59] <chrisf> is obviously going to fall apart as soon as you want to do instancing etc
[05:53:09] *** _28_ria <_28_ria!~igoryonya@194.226.6.106> has quit IRC (Read error: Connection reset by peer)
[05:55:12] *** _28_ria <_28_ria!~igoryonya@194.226.6.106> has joined ##vulkan
[06:02:43] *** tambre <tambre!~tambre@a877-d627-5720-5ddc-0e80-8a31-07d0-2001.dyn.estpak.ee> has joined ##vulkan
[06:14:10] *** tarceri <tarceri!~tarceri@CPE-120-144-40-53.lnse5.win.bigpond.net.au> has joined ##vulkan
[06:28:56] *** zeduckmaster <zeduckmaster!~zeduckmas@85.106.1.181> has joined ##vulkan
[06:55:03] *** _28_ria <_28_ria!~igoryonya@194.226.6.106> has quit IRC (Read error: Connection reset by peer)
[06:58:24] *** _28_ria <_28_ria!~igoryonya@194.226.6.106> has joined ##vulkan
[07:12:27] *** doomlord <doomlord!~textual@host86-148-102-241.range86-148.btcentralplus.com> has joined ##vulkan
[07:25:49] *** bjz <bjz!~bjz@119.225.16.78> has joined ##vulkan
[07:35:17] *** nsf <nsf!~nsf@jiss.convex.ru> has joined ##vulkan
[07:36:40] *** bjz <bjz!~bjz@119.225.16.78> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[07:43:33] *** slidercrank <slidercrank!~slidercra@unaffiliated/slidercrank> has quit IRC (Quit: siht gnidaer er'uoy fi emit eerf hcum oot evah uoy :tiuQ)
[08:10:26] *** GMpow2_2 <GMpow2_2!~5@2a02:810a:83c0:cb14:a9f0:46e7:7886:1259> has joined ##vulkan
[08:15:02] *** GMpow2_3 <GMpow2_3!~5@2a02:810a:83c0:cb14:10dd:5d77:ac4:471d> has joined ##vulkan
[08:18:04] *** GMpow2_2 <GMpow2_2!~5@2a02:810a:83c0:cb14:a9f0:46e7:7886:1259> has quit IRC (Ping timeout: 255 seconds)
[08:21:13] *** GMpow2_3 <GMpow2_3!~5@2a02:810a:83c0:cb14:10dd:5d77:ac4:471d> has quit IRC (Ping timeout: 255 seconds)
[08:26:12] *** lpghatguy <lpghatguy!~LPGhatguy@63.153.99.104> has joined ##vulkan
[08:27:14] *** robot-beethoven <robot-beethoven!~robot-bee@c-73-65-29-166.hsd1.mn.comcast.net> has joined ##vulkan
[08:27:44] *** umm <umm!~TidB@pD9FCEA10.dip0.t-ipconnect.de> has joined ##vulkan
[08:49:30] *** slidercrank <slidercrank!~slidercra@unaffiliated/slidercrank> has joined ##vulkan
[08:56:13] *** realitix <realitix!~realitix@92.103.166.6> has joined ##vulkan
[09:16:28] *** GMpow2_3 <GMpow2_3!~5@2a02:810a:83c0:cb14:c927:7f66:d234:4999> has joined ##vulkan
[09:18:20] *** toor_ <toor_!~toor@76.ip-51-254-204.eu> has joined ##vulkan
[09:19:08] *** GMpow2_2 <GMpow2_2!~5@2a02:810a:83c0:cb14:c927:7f66:d234:4999> has joined ##vulkan
[09:22:16] *** GMpow2_2 <GMpow2_2!~5@2a02:810a:83c0:cb14:c927:7f66:d234:4999> has quit IRC (Remote host closed the connection)
[09:22:25] *** GMpow2_3 <GMpow2_3!~5@2a02:810a:83c0:cb14:c927:7f66:d234:4999> has quit IRC (Ping timeout: 255 seconds)
[09:22:53] *** GMpow2 <GMpow2!~5@ip4d16fc2c.dynamic.kabel-deutschland.de> has joined ##vulkan
[09:25:00] *** robot-beethoven <robot-beethoven!~robot-bee@c-73-65-29-166.hsd1.mn.comcast.net> has quit IRC (Quit: leaving)
[09:26:31] *** nicebyte <nicebyte!~nicebyte@216-243-5-35.users.condointernet.net> has quit IRC (Ping timeout: 245 seconds)
[09:30:48] *** elect <elect!~elect@business-092-079-135-041.static.arcor-ip.net> has joined ##vulkan
[09:55:04] *** doomlord <doomlord!~textual@host86-148-102-241.range86-148.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[09:58:45] *** elect_ <elect_!~elect@business-092-079-135-041.static.arcor-ip.net> has joined ##vulkan
[09:58:49] *** ravior <ravior!~crapitea@5-13-163-37.residential.rdsnet.ro> has joined ##vulkan
[10:00:45] *** elect <elect!~elect@business-092-079-135-041.static.arcor-ip.net> has quit IRC (Ping timeout: 240 seconds)
[10:03:35] *** lpghatguy <lpghatguy!~LPGhatguy@63.153.99.104> has quit IRC (Quit: I'll be back.)
[10:08:04] *** doomlord <doomlord!~textual@host86-148-102-241.range86-148.btcentralplus.com> has joined ##vulkan
[10:08:05] *** ratchetfreak <ratchetfreak!c18021f8@gateway/web/freenode/ip.193.128.33.248> has joined ##vulkan
[10:20:34] *** GMpow2 <GMpow2!~5@ip4d16fc2c.dynamic.kabel-deutschland.de> has quit IRC (Ping timeout: 248 seconds)
[10:24:19] *** ville <ville!~ville@87-95-32-117.bb.dnainternet.fi> has joined ##vulkan
[11:24:42] *** Kingsquee <Kingsquee!~kingsley@d206-116-126-21.bchsia.telus.net> has quit IRC (Quit: https://i.imgur.com/qicT3GK.gif)
[11:26:21] *** TechnoCrunch <TechnoCrunch!~TechnoCru@101.100.137.146> has quit IRC (Read error: Connection reset by peer)
[11:29:29] *** Guest18676 <Guest18676!~jeremy@50-253-122-174-static.hfc.comcastbusiness.net> has quit IRC (Ping timeout: 258 seconds)
[11:45:37] *** bjz <bjz!~bjz@14-201-215-168.tpgi.com.au> has joined ##vulkan
[11:52:48] *** HuntsMan <HuntsMan!~hunts@cpc104822-sgyl39-2-0-cust136.18-2.cable.virginm.net> has quit IRC (Ping timeout: 240 seconds)
[11:53:51] *** ravior <ravior!~crapitea@5-13-163-37.residential.rdsnet.ro> has quit IRC (Quit: Konversation terminated!)
[12:04:00] *** doomlord <doomlord!~textual@host86-148-102-241.range86-148.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[12:05:26] *** doomlord <doomlord!~textual@host86-148-102-241.range86-148.btcentralplus.com> has joined ##vulkan
[12:05:57] *** drasich <drasich!~indefini@124x35x243x164.ap124.ftth.ucom.ne.jp> has quit IRC (Remote host closed the connection)
[12:14:11] *** umm <umm!~TidB@pD9FCEA10.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 252 seconds)
[12:24:32] *** HuntsMan <HuntsMan!~hunts@dhcp9.eps.hw.ac.uk> has joined ##vulkan
[12:35:02] *** john1 <john1!~john@host86-143-93-17.range86-143.btcentralplus.com> has joined ##vulkan
[12:50:47] *** bjz_ <bjz_!~bjz@104.222.140.89> has joined ##vulkan
[12:51:32] *** bjz <bjz!~bjz@14-201-215-168.tpgi.com.au> has quit IRC (Ping timeout: 245 seconds)
[12:56:47] *** jkilpatr <jkilpatr!jkilpatr@nat/redhat/x-dywqelfnwslsmbey> has joined ##vulkan
[13:06:28] *** ravior <ravior!~crapitea@89.121.200.106> has joined ##vulkan
[13:26:21] <tomaka> surprisingly it looks legal to have an descriptor set or descriptor set layout with no descriptor in it at all
[13:26:27] <tomaka> s/an/a/
[13:26:54] <tomaka> my driver happily accepts it as well
[13:27:11] <exDM69> tomaka: well you can have a pipeline that consumes no input
[13:27:28] <tomaka> yeah, but then you wouldn't bind any descriptor set in the first place
[13:27:42] <tomaka> I don't see any point in having empty descriptor sets
[13:28:04] <tomaka> except for the programmer's convenience maybe
[13:28:08] <exDM69> there's no point in forbidding one either
[13:28:43] <tomaka> it's illegal to allocate 0 bytes of memory for example
[13:29:04] <exDM69> it is?
[13:29:13] <exDM69> you mean vkAllocateMemory?
[13:29:17] <tomaka> yeah
[13:29:21] <tomaka> hmm or is it creating a buffer with 0 bytes, I'm not sure
[13:29:59] <baldurk> I haven't thought it through so maybe this isn't it, but could empty descriptor sets be useful for layout compatibility?
[13:30:14] <tomaka> yeah for vkAllocateMemory: >
[13:30:15] <tomaka> allocationSize must be greater than 0
[13:30:16] <baldurk> I am vaguely thinking of e.g. having an empty set 0 so that set 1 can be compatible, or something. I can't remember the exact rules
[13:30:50] <tomaka> and buffers as well: >
[13:30:50] <tomaka> size must be greater than 0
[13:31:11] <tomaka> (come on, I thought I took care to remove the line break)
[13:31:53] <tomaka> for buffers it's actually a bit annoying for high-level code
[13:32:35] <tomaka> suppose you're streaming vertices depending on the camera position, and you allocate your buffer lazily, and for some reason your algorithm produces 0 vertices
[13:32:41] <tomaka> that's a situation that must be taken care of
[13:33:58] <tomaka> I'm thinking of this situation because I got a bug report about precisely this
[13:35:33] *** tacchinotacchi_ <tacchinotacchi_!~tacchinot@net-93-144-206-17.cust.dsl.teletu.it> has quit IRC (Remote host closed the connection)
[13:35:50] *** tacchinotacchi_ <tacchinotacchi_!~tacchinot@net-93-144-206-17.cust.dsl.teletu.it> has joined ##vulkan
[13:37:38] *** bjz <bjz!~bjz@14-201-215-168.tpgi.com.au> has joined ##vulkan
[13:39:19] *** bjz_ <bjz_!~bjz@104.222.140.89> has quit IRC (Ping timeout: 255 seconds)
[13:39:22] *** harishkrupo <harishkrupo!~user@134.134.137.73> has joined ##vulkan
[13:40:13] *** harishkrupo <harishkrupo!~user@134.134.137.73> has quit IRC (Client Quit)
[13:40:23] *** harishkrupo <harishkrupo!user@nat/intel/x-nxptmjreovqxxlgf> has joined ##vulkan
[13:40:27] *** harishkrupo <harishkrupo!user@nat/intel/x-nxptmjreovqxxlgf> has left ##vulkan
[14:03:09] *** GMpow2 <GMpow2!~5@2a02:810a:83c0:cb14:ac45:1217:37b1:98f4> has joined ##vulkan
[14:03:42] <tomaka> I don't understand something about the new constants for color spaces
[14:03:55] <tomaka> There's for example this: > VK_COLOR_SPACE_BT2020_LINEAR_EXT - supports the BT2020 color space and applies a linear OETF.
[14:04:00] <tomaka> Or this: > VK_COLOR_SPACE_BT2020_NONLINEAR_EXT - supports the BT2020 color space and applies the SMPTE 170M OETF.
[14:04:43] <tomaka> Apparently both mean that the monitor supports colors in the BT2020 color space, but in the second one the hardware performs an additional conversion of some sort from the values of the shaders to the actual colors
[14:04:52] <tomaka> so far so good
[14:05:02] <tomaka> Except that the text says: > Vulkan requires that all implementations support the sRGB OETF and EOTF when using an SRGB pixel format. Other transfer functions, such as SMPTE 170M, must not: be performed by the implementation, but can be performed by the application shader.
[14:05:45] <tomaka> so basically, you can choose between VK_COLOR_SPACE_BT2020_LINEAR_EXT and VK_COLOR_SPACE_BT2020_NONLINEAR_EXT, but the text says that the two do the same thing?
[14:06:09] <tomaka> It's confirmed below: > Extension indicates that implementation must not do the OETF encoding if it’s not sRGB. That responsibility falls to the application shaders.
[14:06:16] <tomaka> (link for the lazy: https://www.khronos.org/registry/vulkan/specs/1.0-extensions/html/vkspec.html#VK_EXT_swapchain_colorspace)
[14:07:14] <tomaka> wait I'm confused now
[14:07:28] <exDM69> colorspaces are confusing...
[14:09:04] <tomaka> ok I guess I get it
[14:09:32] <tomaka> if you use any VK_COLOR_SPACE_*_LINEAR, then you will always get the same colors, whatever the color space is
[14:09:56] <tomaka> but if you use VK_COLOR_SPACE_*_NONLINEAR, then the output of your fragment shader will be interpreted as already being in the color space of the monitor
[14:10:04] <tomaka> except for sRGB... ugh that's weird
[14:11:14] <tomaka> oh I guess if you use a sRGB texture format for the images with COLOR_SPACE_SRGB, then the output of your framgnet shader will be converted by the hardware into sRGB
[14:11:34] <tomaka> and if you use a non-sRGB texture format with COLOR_SPACE_SRGB, then the output will be interpreted as already in sRGB?
[14:19:56] <tomaka> or maybe it's the contrary, LINEAR maps the output of the fragment shader to the limits of the monitor, while NONLINEAR interprets the values
[14:20:09] <tomaka> err
[14:25:36] *** harishkrupo <harishkrupo!user@nat/intel/x-bggppytgvlduyjzi> has joined ##vulkan
[14:25:56] <harishkrupo> How do i compile vulkan intel driver in ubuntu 14.04?
[14:39:53] <realitix> harishkrupo: https://realitix.github.io/vulkan/2016/06/28/first-post/
[14:40:16] <realitix> Ubuntu 16.04 but it's a good start for you
[14:40:51] *** Rangar <Rangar!~Dave@101.98.215.224> has quit IRC (Read error: Connection reset by peer)
[14:41:02] *** neurrre <neurrre!~tsuorant@a91-155-31-190.elisa-laajakaista.fi> has joined ##vulkan
[14:42:50] *** Rangar <Rangar!~Dave@101.98.215.224> has joined ##vulkan
[14:43:05] *** Salek <Salek!~salek@91-159-91-43.elisa-laajakaista.fi> has quit IRC (Ping timeout: 240 seconds)
[14:43:16] *** Salek <Salek!~salek@91-159-91-43.elisa-laajakaista.fi> has joined ##vulkan
[14:44:11] *** neurre <neurre!~tsuorant@a91-155-31-190.elisa-laajakaista.fi> has quit IRC (Ping timeout: 276 seconds)
[14:44:32] *** neurre <neurre!~tsuorant@a91-155-31-190.elisa-laajakaista.fi> has joined ##vulkan
[14:46:07] *** neurrre <neurrre!~tsuorant@a91-155-31-190.elisa-laajakaista.fi> has quit IRC (Ping timeout: 258 seconds)
[14:51:56] *** kdub <kdub!~kdub@d28-23-138-68.dim.wideopenwest.com> has quit IRC (Quit: goodnight)
[14:53:02] *** kdub <kdub!~kdub@d28-23-138-68.dim.wideopenwest.com> has joined ##vulkan
[14:57:10] *** doomlord <doomlord!~textual@host86-148-102-241.range86-148.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[15:01:38] *** nsf <nsf!~nsf@jiss.convex.ru> has quit IRC (Quit: WeeChat 1.7)
[15:01:56] *** kdub <kdub!~kdub@d28-23-138-68.dim.wideopenwest.com> has quit IRC (Quit: goodnight)
[15:02:51] *** kdub <kdub!~kdub@d28-23-138-68.dim.wideopenwest.com> has joined ##vulkan
[15:05:13] *** GMpow2 <GMpow2!~5@2a02:810a:83c0:cb14:ac45:1217:37b1:98f4> has quit IRC (Remote host closed the connection)
[15:05:40] *** GMpow2 <GMpow2!~5@2a02:810a:83c0:cb14:ac45:1217:37b1:98f4> has joined ##vulkan
[15:14:59] *** slidercrank <slidercrank!~slidercra@unaffiliated/slidercrank> has quit IRC (Quit: Leaving)
[15:42:46] <salamanderrake> https://www.youtube.com/watch?v=CJqDyLDlIV4&feature=youtu.be Yaakuro has UE4 with Vulkan SM4 partially working on Linux.
[15:43:42] *** ZexaronS <ZexaronS!~zexpc@cpe-194-152-22-45.static.triera.net> has joined ##vulkan
[15:46:42] *** kvark <kvark!~sid944@2620:101:8016:74::5:3b0> has quit IRC (Ping timeout: 256 seconds)
[15:46:47] *** GreaseMonkey <GreaseMonkey!greaser@unaffiliated/greasemonkey> has quit IRC (Remote host closed the connection)
[15:48:54] *** greaser|q <greaser|q!greaser@antihype.space> has joined ##vulkan
[15:51:04] *** kvark <kvark!sid944@gateway/web/mozilla/x-kpsrvkuclrufcslp> has joined ##vulkan
[15:57:01] *** [xyzzy] <[xyzzy]!~xyzzy@2600:8803:e400:d600:d52a:3c49:1752:3529> has quit IRC (Ping timeout: 255 seconds)
[16:02:55] *** [xyzzy] <[xyzzy]!~xyzzy@2600:8803:e400:d600:2d36:2e85:47c6:cde3> has joined ##vulkan
[16:07:04] *** doomlord <doomlord!~textual@host86-148-102-241.range86-148.btcentralplus.com> has joined ##vulkan
[16:10:41] *** zeduckmaster <zeduckmaster!~zeduckmas@85.106.1.181> has quit IRC (Ping timeout: 240 seconds)
[16:18:44] <lieff[m]> wow, great
[16:29:32] *** john1 <john1!~john@host86-143-93-17.range86-143.btcentralplus.com> has quit IRC (Quit: WeeChat 1.7)
[16:33:25] <haagch> not great performance tho
[16:33:43] <haagch> has some way to go until it's good enough for steamvr on linux
[16:33:48] <salamanderrake> no, its still a bit off, but at least he got it working.
[16:38:14] *** nsf <nsf!~nsf@jiss.convex.ru> has joined ##vulkan
[16:41:40] *** doomlord <doomlord!~textual@host86-148-102-241.range86-148.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[16:42:00] *** john1 <john1!~john@host86-143-93-17.range86-143.btcentralplus.com> has joined ##vulkan
[16:50:49] *** ector <ector!~asdf@37-247-11-157.customers.ownit.se> has joined ##vulkan
[17:05:42] *** C-Man <C-Man!~Coldberg@78-56-219-19.static.zebra.lt> has joined ##vulkan
[17:14:57] *** jeremy <jeremy!~jeremy@50-253-122-174-static.hfc.comcastbusiness.net> has joined ##vulkan
[17:15:20] *** jeremy is now known as Guest74768
[17:16:05] *** nidefawl <nidefawl!~nidefawl@p5DDE4EA9.dip0.t-ipconnect.de> has joined ##vulkan
[17:27:33] *** doomlord <doomlord!~textual@host86-148-102-241.range86-148.btcentralplus.com> has joined ##vulkan
[17:28:14] *** nidefawl <nidefawl!~nidefawl@p5DDE4EA9.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 252 seconds)
[17:29:03] *** nidefawl <nidefawl!~nidefawl@p57B2FA06.dip0.t-ipconnect.de> has joined ##vulkan
[17:44:09] *** umm <umm!~TidB@pD9FCEA10.dip0.t-ipconnect.de> has joined ##vulkan
[17:44:45] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has joined ##vulkan
[18:13:09] *** ratchetfreak <ratchetfreak!c18021f8@gateway/web/freenode/ip.193.128.33.248> has quit IRC (Ping timeout: 260 seconds)
[18:29:03] *** afl_ext <afl_ext!~afl_ext3@acnt79.neoplus.adsl.tpnet.pl> has joined ##vulkan
[18:29:04] *** afl_ext <afl_ext!~afl_ext3@acnt79.neoplus.adsl.tpnet.pl> has quit IRC (Changing host)
[18:29:04] *** afl_ext <afl_ext!~afl_ext3@unaffiliated/afl-ext/x-2796036> has joined ##vulkan
[18:36:08] *** nsf <nsf!~nsf@jiss.convex.ru> has quit IRC (Quit: WeeChat 1.7)
[18:43:01] <ZexaronS> hello
[18:43:06] <ZexaronS> guys i've been thinking
[18:43:47] *** sla_ro|master <sla_ro|master!~sla.ro@95.76.45.217> has joined ##vulkan
[18:43:48] <ZexaronS> isn't this whole texture stuff so old, I'm in DCS World doing some skinning, and I just think this whole idea of DXT compression has to be replaced and I'm seeing some BC7 stuff from intel
[18:44:06] <ZexaronS> we finally have the new APIs like Vulkan, time to get these old bottlenecks out of our way
[18:44:39] <ZexaronS> I just had a rant in my mind, the industry decided on their own "what looks good enough" and when you want higher quality textures they always only talk about resolution
[18:45:14] <ZexaronS> and the whole industry talks about the how stuff will go in future and how it will look good, but this compression thing is been going on for years, you can't see any text up close
[18:45:41] *** HuntsMan <HuntsMan!~hunts@dhcp9.eps.hw.ac.uk> has quit IRC (Ping timeout: 258 seconds)
[18:45:57] <ZexaronS> I hope progress is being made in this area, and I didn't research that much, but I hope that GPUs nativel would start supporting more than DTX, at least 8.8.8.8 uncompressed stuff
[18:46:57] <baldurk> it sounds like you might have to do some reading about how and why compression happens, as you have a few mistaken assumptions
[18:47:31] <ZexaronS> So the industry lower the bar, and then says this is the normal, why don't we turn it around and say THAT is the normal, now the devs will complain they can't make a game that large because it's going to take a lot more RAM, well, sorry, you're just gonna have to wait for better hardware in future, THAT'S WHAT IT TAKES
[18:47:36] <Yaniel> GPUs have always supported uncompressed formats
[18:47:52] <ZexaronS> I must have heard some guy without experience then
[18:48:14] <Yaniel> feel free to make a game that uses f32 textures for everything
[18:48:18] <ZexaronS> He said, with DXT is goes directly used by the GPU so it's faster than 8.8.8.8
[18:48:53] *** realitix <realitix!~realitix@92.103.166.6> has quit IRC (Quit: Leaving)
[18:48:56] <Yaniel> rgb8 is also used by the GPU "directly"
[18:49:22] <Yaniel> it's just like 8x the amount of data to copy around
[18:50:20] <Yaniel> storing the data is not the issue here
[18:50:31] <Yaniel> getting it where it's needed is
[18:50:34] <ZexaronS> Well, I'm not saying that compression it self is a problem, surely some compression will help HDD space and RAM/GRAM but it should be lossless or very low loss one, should still compress versus totally uncompressed, exactly what FLAC is like, that's what we need
[18:51:01] <ZexaronS> So I found out about this Intel DDS Texture Works and their BC7, is this similar to what my idea of FLAC is ?
[18:51:42] <tomaka> you can't do lossless texture compression while still keeping each pixel easily accessible
[18:51:53] <tomaka> that's mathematically impossible I think
[18:52:13] <ZexaronS> Yaniel, oh so, I kinda see where the problem could be, the speed of the buses and the speed of the memory it self, and the interlinks inside the GPU ... right
[18:52:16] <Yaniel> FLAC has quite different requirements
[18:52:37] <Yaniel> ZexaronS: do you know what registers are?
[18:52:51] <Yaniel> or about ALU architecture in general
[18:52:52] <ZexaronS> I heard of them, but nope
[18:53:05] <Yaniel> read up
[18:53:06] <ZexaronS> I learn fast tho
[18:53:23] <ZexaronS> Cause I'm pretty much around these waters for years
[18:53:29] <Yaniel> it'll hopefully explain why transferring data is a problem
[18:53:35] <Yaniel> if not, come back to ask ;)
[18:57:37] <ZexaronS> That's reasonable, but, what if the whole industry never knew about such compression, and would simply use uncompressed as the normal, would we simply stop and don't evolve the technology to eventually get to these levels we are now, it would just be a different flavored path
[18:58:16] *** BearishMushroom <BearishMushroom!~BearishMu@90-231-174-194-no159.tbcn.telia.com> has joined ##vulkan
[18:58:16] <Yaniel> we would probably still be using 128x128 textures then
[18:58:29] <Yaniel> or graphics cards would cost an order of magnitude more
[18:58:33] <fazias> memory bandwidth is limited :|
[18:58:40] <baldurk> you seem to have it backwards. Block compression is the improved technology, over uncompressed formats
[18:58:50] <fazias> +1
[18:58:51] <baldurk> older games used to pack using fewer bits, like 5:6:5
[18:59:01] <ZexaronS> So, as the marketing side of the industry is talking how big advancements are made, bla bla, talking about the future, oh you see what the future has in store for us, but you look at it technically, they are constantly cutting corners and dumbing things down to get "there"
[18:59:05] <baldurk> or dithered/palettised
[18:59:41] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-82s3g7l9r42569r41f4.18120a2.ip6.access.telenet.be> has joined ##vulkan
[18:59:48] <Yaniel> yeah 256 color mode :3
[18:59:57] <Yaniel> who needs 32bit color anyway
[18:59:57] <fazias> Well, there is also the thing that most ppl prefer 60fps games.
[19:00:24] <Yaniel> or even 10:10:10
[19:00:58] <Yaniel> curiously, the "standard" fps has increased as well
[19:01:06] <fazias> :D
[19:01:13] <Yaniel> remember all those 30fps consoles?
[19:01:23] <fazias> also bc7 is pretty cool.
[19:01:42] <ZexaronS> It's simple, games wouldn't be that big and expansive, but who knows for sure, maybe the technology would evolve faster and you'd have a 128GB GPU sitting by your right now, I think a lot of tech is basically being separated into iterations so they can have more cycles and more milking, same technology being rehashed with little updates
[19:01:49] <Yaniel> or the max 10fps animations in all 2d games
[19:02:08] *** nicebyte <nicebyte!nicebyte@nat/google/x-fjgdhknbrsyconvm> has joined ##vulkan
[19:02:10] <fazias> Well, you cannot just add memory and expect it to work faster :D
[19:02:12] <baldurk> I didn't realise I'd accidentally joined #conspiracy-theories
[19:02:29] <fazias> the same reason why cpu's don't have super big caches, it just doesn't work like that.
[19:03:01] <Yaniel> the laws of physics are a hoax! invented by the martians!
[19:03:28] <fazias> Apparently!
[19:03:28] <eric_engestrom> btw, anyone interested in texture compressions should have a look at Binomial's Basis ;)
[19:03:31] <eric_engestrom> https://docs.google.com/presentation/d/19B0ji4P1YgNlaEbmW89UkY-laWfIRJGcIubfH8uwT20/edit
[19:05:03] <ZexaronS> There's a lot of tech companies only develop and sell to the military, like https://www.youtube.com/watch?v=woAIyu8nzig , why, because they simply don't have any interest they don't really care, what if everyone had an opposite mindset, we would be having starbase right now.
[19:05:39] <Yaniel> what I'm more concerned about is that there's no universal standard for texture compression
[19:05:53] *** echotangoecho <echotangoecho!~echotango@dhcp-089-098-177-067.chello.nl> has joined ##vulkan
[19:05:55] <Yaniel> largely because companies like to go "muh IPR"
[19:06:05] <ZexaronS> I would agree
[19:06:33] <eric_engestrom> re: "universal standard for texture compression", have a look at the slides I just linked :)
[19:07:45] <Yaniel> eric_engestrom: I saw them some days ago ^^ they're indeed a breath of fresh air
[19:07:59] <ZexaronS> Oh interesting, supercompressed ... as long as it looks better than DXT5 im fine with however your call it
[19:08:35] <baldurk> basis is awesome but it's kind of independent of the question of GPU compression formats
[19:10:58] <fazias> O.o sounds interesting. I guess I would like to see more of basis.
[19:12:14] <baldurk> Binomial's part of khronos now, I was suggesting that it'd be *really* cool if there were a KHR extension to expose some kind of transfer command to copy from host memory to device memory and transcode at the same time. That way the GPU compression format could be opaque, and the application only needs to deal with basis on all platforms
[19:12:46] <baldurk> so no need to build multiple data packs with each of ASTC, BCn, PVRTC or whatever
[19:13:28] *** elect_ <elect_!~elect@business-092-079-135-041.static.arcor-ip.net> has quit IRC (Ping timeout: 260 seconds)
[19:25:19] *** ravior <ravior!~crapitea@89.121.200.106> has quit IRC (Quit: Konversation terminated!)
[19:25:24] *** jkilpatr_ <jkilpatr_!jkilpatr@nat/redhat/x-hwftnnnwqgvdbpoz> has joined ##vulkan
[19:26:29] <nicebyte> maybe if it's widespread enough, gpu vendors will consider supporting it natively :)
[19:26:44] <tomaka> I'm not sure it can be done transparently
[19:27:03] <tomaka> you probably still need to somehow know for example the size in bytes of the texture and things like that
[19:27:16] <tomaka> size in bytes once decompressed
[19:27:41] *** HuntsMan <HuntsMan!~hunts@cpc104822-sgyl39-2-0-cust136.18-2.cable.virginm.net> has joined ##vulkan
[19:27:43] <baldurk> it's not very good for GPU access, since they want to be able to grab some number of bytes (8, 16, whatever) for a block of pixels at random without decoding the bytes before it
[19:27:46] *** jkilpatr <jkilpatr!jkilpatr@nat/redhat/x-dywqelfnwslsmbey> has quit IRC (Ping timeout: 240 seconds)
[19:36:06] *** afl_ext <afl_ext!~afl_ext3@unaffiliated/afl-ext/x-2796036> has quit IRC (Quit: Leaving)
[19:37:22] *** ector <ector!~asdf@37-247-11-157.customers.ownit.se> has quit IRC ()
[19:46:51] <nicebyte> in that case, what did they mean when they said that GPU decoding was totally possible too?
[19:47:11] <baldurk> I believe they meant doing the transcoding on the GPU rather than the CPU
[19:47:13] <baldurk> in compute
[19:47:14] <tomaka> you can use a compute shader I guess?
[19:47:41] <nicebyte> oh i see
[19:47:53] *** soreau <soreau!~soreau@unaffiliated/soreau> has quit IRC (Ping timeout: 260 seconds)
[20:01:43] *** soreau <soreau!~soreau@unaffiliated/soreau> has joined ##vulkan
[20:04:33] *** ricardassim <ricardassim!~ricardass@78.63.172.44> has joined ##vulkan
[20:11:28] *** tacchinotacchi_ <tacchinotacchi_!~tacchinot@net-93-144-206-17.cust.dsl.teletu.it> has quit IRC (Remote host closed the connection)
[20:12:25] *** tacchinotacchi_ <tacchinotacchi_!~tacchinot@net-93-144-206-17.cust.dsl.teletu.it> has joined ##vulkan
[20:18:53] *** echotangoecho <echotangoecho!~echotango@dhcp-089-098-177-067.chello.nl> has quit IRC (Quit: leaving)
[20:23:43] <ZexaronS> the inudstry especially the easy-peasy web-flashy-treny will get a rought wakeup call
[20:24:04] <ZexaronS> all these formats will be worthless when HDR and Rec2020 arrive
[20:25:34] <ZexaronS> I was about to ask if they make backward compatible, I guess they do https://en.wikipedia.org/wiki/JPEG-HDR
[20:28:08] *** derhass <derhass!~derhass@ipservice-092-216-126-046.092.216.pools.vodafone-ip.de> has joined ##vulkan
[20:28:21] <baldurk> block compression isn't the same as JPEG, and the majority of textures that are block compressed don't need to store any HDR data anyway (and for those that do, BC6 is widely available)
[20:31:23] <ZexaronS> I'm just not fond of the DDS texture editing, usually with modding, as things ingame get stretched, and then those pixels get enlarged to fill or how does it work ... the pipeline is just I don't agree with it
[20:32:00] <ZexaronS> Might be something the developers don't provide to the public, rather than a technical limitations, AFAIK it has to do with how DDS are stored in a file right ?
[20:32:59] <baldurk> if you're editing an already block compressed texture then the quality will likely reduce, because you're re-compressing the data. In theory blocks you don't change can just be passed through as-is, but I doubt any tool will take advantage of that except by luck
[20:33:03] <ZexaronS> But this is old stuff, I don't know how it is with PBR, I will tackle UE4 later this year
[20:33:16] <ZexaronS> After 4.15 comes out, just waiting for that
[20:34:12] <ZexaronS> Oh, I do have PSD templates for the main parts, just some decals don't have PSD provided, so I modified the existing DDS
[20:34:51] <ZexaronS> But it's the same thing in PSD, it's still a flat 2D surface
[20:35:13] <ZexaronS> Then it gets wrapped around an aircraft which is, half the time round
[20:38:27] <ZexaronS> Adobe Photoshop should kinda be more supportive of such computer game texturing, you could have a standardized texture file where the "DDS" texture would contain the wrap-around metadata, basically the 3D model silhouette, you'd open the texture and it would look as a model, then you'd paint with photosop style tools on there
[20:39:19] <ZexaronS> If you'd open that with a program that doesn't support such, it would display the usual 2D flat surface of textures
[20:40:14] <ZexaronS> With that 3D ability, you wouldn't have to check and to a ton of trial and errors and it would be way more productive, you'd still have the layering like PSD
[20:40:46] <baldurk> you're basically describing zbrush, and other tools like that
[20:40:49] <Yaniel> you basically described blender's texture painting functionality
[20:40:54] <baldurk> hah
[20:41:17] <ZexaronS> Aren't those more for modelling ?
[20:41:43] <Yaniel> texturing is as much part of modelling as sculpting or whatever method you use for bulding the mesh
[20:41:50] <ZexaronS> I see blender more for movie scene rendering, than game development, but I could be wrong, I did try out blender for a few days
[20:42:08] <Yaniel> and given your aversion to the "industry" I'm surprised you are so fond of photoshop
[20:42:47] <baldurk> Yaniel: clearly Adobe aren't part of the secret lizard people society that are beaming illuminati secrets into your GPU
[20:43:06] <ZexaronS> Maybe, what I'm trying to say is, these 2 things should be done together, rather than separated like the inudstry usually was, 3DSMax and Photoshop
[20:43:40] <Yaniel> photoshop isn't really a texturing tool anyway
[20:43:52] <Yaniel> you might notice how it's called 'photo'shop
[20:44:50] *** nsf <nsf!~nsf@jiss.convex.ru> has joined ##vulkan
[20:44:57] <ZexaronS> Yaniel: eeeemmm The source files are PSD , unless I can convert PSD to blender or Zbrush formats and if one of those then supports the DDS/DXT exporting
[20:45:41] <ZexaronS> It's the devs that don't provide other templates
[20:45:43] *** umm_ <umm_!~TidB@pD95D48FA.dip0.t-ipconnect.de> has joined ##vulkan
[20:45:46] *** umm_ <umm_!~TidB@pD95D48FA.dip0.t-ipconnect.de> has quit IRC (Client Quit)
[20:46:04] <ZexaronS> So they are wrong originally, they use photoshop, half the indusssssssssssssssss
[20:46:04] <ZexaronS> +đđ
[20:46:08] <ZexaronS> ćđ
[20:46:08] <ZexaronS> đ
[20:46:08] <ZexaronS> đ
[20:46:10] <ZexaronS> sorry
[20:46:13] <ZexaronS> keyboard
[20:46:25] <Yaniel> not surprising, because marketing and photoshop being the de facto hammer for all your graphical nails
[20:46:44] <Yaniel> regardless of what shape said nails have
[20:46:47] *** umm <umm!~TidB@pD9FCEA10.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 252 seconds)
[20:47:48] *** jkilpatr_ <jkilpatr_!jkilpatr@nat/redhat/x-hwftnnnwqgvdbpoz> has quit IRC (Ping timeout: 240 seconds)
[20:51:22] *** umm <umm!~TidB@pD95D48FA.dip0.t-ipconnect.de> has joined ##vulkan
[20:52:21] *** ravior <ravior!~crapitea@5-13-197-50.residential.rdsnet.ro> has joined ##vulkan
[21:01:20] *** jkilpatr_ <jkilpatr_!jkilpatr@nat/redhat/x-giuidoatjuaqdasv> has joined ##vulkan
[21:18:45] *** nicebyte <nicebyte!nicebyte@nat/google/x-fjgdhknbrsyconvm> has quit IRC (Ping timeout: 255 seconds)
[21:19:24] *** tambre <tambre!~tambre@a877-d627-5720-5ddc-0e80-8a31-07d0-2001.dyn.estpak.ee> has quit IRC (Ping timeout: 258 seconds)
[21:25:02] *** nicebyte <nicebyte!nicebyte@nat/google/x-fiefdjvsusecvtpg> has joined ##vulkan
[21:35:52] *** ZexaronS <ZexaronS!~zexpc@cpe-194-152-22-45.static.triera.net> has quit IRC (Quit: Leaving)
[21:45:53] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has quit IRC (Quit: Leaving)
[21:51:29] *** robot-beethoven <robot-beethoven!~robot-bee@c-73-65-29-166.hsd1.mn.comcast.net> has joined ##vulkan
[21:55:51] *** hellyeah <hellyeah!0e99c5de@gateway/web/freenode/ip.14.153.197.222> has joined ##vulkan
[21:57:44] *** hellyeah <hellyeah!0e99c5de@gateway/web/freenode/ip.14.153.197.222> has left ##vulkan
[21:57:52] *** nicebyte <nicebyte!nicebyte@nat/google/x-fiefdjvsusecvtpg> has quit IRC (Remote host closed the connection)
[21:57:54] *** hellyeah <hellyeah!0e99c5de@gateway/web/freenode/ip.14.153.197.222> has joined ##vulkan
[21:58:05] *** nicebyte <nicebyte!nicebyte@nat/google/x-xmmwxejprdsokevv> has joined ##vulkan
[22:05:06] *** ville <ville!~ville@87-95-32-117.bb.dnainternet.fi> has quit IRC (Ping timeout: 255 seconds)
[22:07:03] *** ville <ville!~ville@87-93-113-60.bb.dnainternet.fi> has joined ##vulkan
[22:09:44] <hellyeah> anybody know why after run build_examples.sh, I got an shared library cube but not executable
[22:10:31] <hellyeah> and cubepp is an executable file
[22:13:40] *** soreau <soreau!~soreau@unaffiliated/soreau> has quit IRC (Ping timeout: 240 seconds)
[22:18:32] *** jkilpatr_ <jkilpatr_!jkilpatr@nat/redhat/x-giuidoatjuaqdasv> has quit IRC (Ping timeout: 276 seconds)
[22:20:25] *** slidercrank <slidercrank!~slidercra@unaffiliated/slidercrank> has joined ##vulkan
[22:37:19] *** afl_ext <afl_ext!~afl_ext3@unaffiliated/afl-ext/x-2796036> has joined ##vulkan
[22:39:45] *** pdq <pdq!~pdq@unaffiliated/pdq> has quit IRC (Ping timeout: 255 seconds)
[22:40:57] *** pdq <pdq!~pdq@162.243.194.120> has joined ##vulkan
[22:42:58] *** neurre <neurre!~tsuorant@a91-155-31-190.elisa-laajakaista.fi> has quit IRC (Ping timeout: 258 seconds)
[22:53:06] *** jkilpatr_ <jkilpatr_!~jkilpatr@2602:30a:c7da:b600:1202:b5ff:fe3b:d41d> has joined ##vulkan
[22:57:18] *** hellyeah <hellyeah!0e99c5de@gateway/web/freenode/ip.14.153.197.222> has quit IRC (Quit: Page closed)
[23:05:26] *** GMpow2 <GMpow2!~5@2a02:810a:83c0:cb14:ac45:1217:37b1:98f4> has quit IRC (Remote host closed the connection)
[23:05:53] *** GMpow2 <GMpow2!~5@2a02:810a:83c0:cb14:ac45:1217:37b1:98f4> has joined ##vulkan
[23:15:27] *** nicebyte <nicebyte!nicebyte@nat/google/x-xmmwxejprdsokevv> has quit IRC (Read error: Connection reset by peer)
[23:17:36] *** bjz <bjz!~bjz@14-201-215-168.tpgi.com.au> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[23:21:00] *** ZexaronS <ZexaronS!~zexpc@cpe-194-152-22-45.static.triera.net> has joined ##vulkan
[23:38:05] *** bjz <bjz!~bjz@pa49-183-58-13.pa.vic.optusnet.com.au> has joined ##vulkan
[23:42:17] *** sla_ro|master <sla_ro|master!~sla.ro@95.76.45.217> has quit IRC ()
[23:42:17] *** afl_ext <afl_ext!~afl_ext3@unaffiliated/afl-ext/x-2796036> has quit IRC (Quit: Leaving)
[23:48:03] *** bjz <bjz!~bjz@pa49-183-58-13.pa.vic.optusnet.com.au> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[23:51:02] *** umm <umm!~TidB@pD95D48FA.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 252 seconds)
[23:55:06] *** w-t-h_ <w-t-h_!~chatzilla@72.67.52.110> has joined ##vulkan
top

   January 31, 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 | 29 | 30 | 31 | >