Switch to DuckDuckGo Search
   February 27, 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 | >

Toggle Join/Part | bottom
[00:07:10] *** lpghatguy <lpghatguy!~lpghatguy@2601:642:4301:3830:3985:5061:be07:8218> has quit IRC (Remote host closed the connection)
[00:08:09] *** lpghatguy <lpghatguy!~lpghatguy@2601:642:4301:3830:f1ae:900e:76e2:1301> has joined ##vulkan
[00:08:28] *** john3 <john3!~john@host86-143-90-12.range86-143.btcentralplus.com> has quit IRC (Ping timeout: 260 seconds)
[00:27:30] *** john3 <john3!~john@host86-143-90-12.range86-143.btcentralplus.com> has joined ##vulkan
[00:27:41] *** ector <ector!~asdf@37-247-11-157.customers.ownit.se> has quit IRC ()
[00:34:09] *** toor is now known as Guest97756
[00:34:09] *** Guest97756 <Guest97756!~toor@51.254.204.76> has quit IRC (Killed (cherryh.freenode.net (Nickname regained by services)))
[00:34:26] *** Guest97756 <Guest97756!~toor@76.ip-51-254-204.eu> has joined ##vulkan
[00:47:57] *** echotangoecho <echotangoecho!~echotango@dhcp-089-098-177-067.chello.nl> has quit IRC (Remote host closed the connection)
[00:49:14] *** _28_ria <_28_ria!~igoryonya@opfr028.ru> has quit IRC (Read error: Connection reset by peer)
[00:50:37] *** _28_ria <_28_ria!~igoryonya@opfr028.ru> has joined ##vulkan
[01:03:24] *** Jackneill_ <Jackneill_!~Jackneill@unaffiliated/jackneill> has quit IRC (Remote host closed the connection)
[01:16:57] *** [xyzzy] <[xyzzy]!~xyzzy@2600:8803:e400:d600:cc05:33f1:5374:3586> has joined ##vulkan
[01:35:27] *** slidercrank <slidercrank!~slidercra@unaffiliated/slidercrank> has quit IRC (Ping timeout: 240 seconds)
[01:43:16] *** rlarionov <rlarionov!~rlarionov@68-202-221-190.res.bhn.net> has joined ##vulkan
[02:04:37] *** derhass <derhass!~derhass@ipservice-092-216-126-046.092.216.pools.vodafone-ip.de> has quit IRC (Quit: leaving)
[02:10:52] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-82s3g7l9r42569r41f4.18120a2.ip6.access.telenet.be> has quit IRC (Ping timeout: 255 seconds)
[02:15:01] *** rlarionov <rlarionov!~rlarionov@68-202-221-190.res.bhn.net> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
[02:30:52] *** joakim <joakim!uid154127@gateway/web/irccloud.com/x-wsofjymftfbqmhjp> has quit IRC (Quit: Connection closed for inactivity)
[02:35:08] *** BearishMushroom <BearishMushroom!~BearishMu@90-231-174-194-no159.tbcn.telia.com> has quit IRC (Read error: Connection reset by peer)
[02:47:20] *** doomlord <doomlord!~textual@host86-176-242-250.range86-176.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[02:50:30] *** CaptainLex <CaptainLex!~CaptainLe@67-220-31-207.fttp.usinternet.com> has quit IRC (Remote host closed the connection)
[03:00:36] <nidefawl> Is there a way to make gslangvalidator optimize away unused vertex attributes?
[03:01:39] <chrisf> nidefawl: there may be passes in spirv-opt that do what you want
[03:02:08] <chrisf> nidefawl: glslangValidator itself produces fairly braindead code
[03:08:27] *** w-t-h_ <w-t-h_!~chatzilla@72.67.52.110> has quit IRC (Ping timeout: 240 seconds)
[03:09:18] <nidefawl> Oh, damn. I assumed there was some basic optimization going on already
[03:21:33] *** herbmillerjr <herbmillerjr!~herb@c-76-120-173-141.hsd1.pa.comcast.net> has quit IRC (Quit: Konversation terminated!)
[03:28:17] *** doomlord <doomlord!~textual@host86-176-242-250.range86-176.btcentralplus.com> has joined ##vulkan
[03:33:10] *** TechnoCrunch <TechnoCrunch!~TechnoCru@101.100.137.146> has joined ##vulkan
[03:34:11] *** Feedz <Feedz!~Feedz@unaffiliated/feedz> has quit IRC (Read error: Connection reset by peer)
[03:48:58] *** GMpow2 <GMpow2!~5@2a02:810a:83c0:cb14:c8e9:d453:13c0:2ee4> has quit IRC (Ping timeout: 255 seconds)
[03:58:51] *** slidercrank <slidercrank!~slidercra@unaffiliated/slidercrank> has joined ##vulkan
[04:01:48] *** GMpow3srV <GMpow3srV!~goedelmac@55d449cd.access.ecotel.net> has joined ##vulkan
[04:05:32] *** GMpow2srV <GMpow2srV!~goedelmac@55d44dc3.access.ecotel.net> has quit IRC (Ping timeout: 268 seconds)
[04:37:02] *** kuldeep <kuldeep!~kuldeepdh@unaffiliated/kuldeepdhaka> has quit IRC (Remote host closed the connection)
[04:37:24] *** kuldeep <kuldeep!~kuldeepdh@unaffiliated/kuldeepdhaka> has joined ##vulkan
[04:51:43] *** slidercrank <slidercrank!~slidercra@unaffiliated/slidercrank> has quit IRC (Quit: siht gnidaer er'uoy fi emit eerf hcum oot evah uoy :tiuQ)
[04:59:49] *** GMpow5srV <GMpow5srV!~goedelmac@55d45536.access.ecotel.net> has joined ##vulkan
[05:03:30] *** GMpow3srV <GMpow3srV!~goedelmac@55d449cd.access.ecotel.net> has quit IRC (Ping timeout: 268 seconds)
[05:28:45] *** marcheu <marcheu!~marcheu@annarchy.freedesktop.org> has joined ##vulkan
[05:33:44] *** doomlord <doomlord!~textual@host86-176-242-250.range86-176.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[05:37:50] *** rlarionov <rlarionov!~rlarionov@68-202-221-190.res.bhn.net> has joined ##vulkan
[05:38:18] *** rlarionov <rlarionov!~rlarionov@68-202-221-190.res.bhn.net> has quit IRC (Client Quit)
[05:51:45] *** slidercrank <slidercrank!~slidercra@unaffiliated/slidercrank> has joined ##vulkan
[06:00:27] *** ZexaronS <ZexaronS!~zexpc@cpe-194-152-22-45.static.triera.net> has joined ##vulkan
[06:09:26] *** tambre <tambre!~tambre@7e05-da60-b3de-657d-0e80-8a31-07d0-2001.dyn.estpak.ee> has joined ##vulkan
[07:10:43] *** robot-beethoven <robot-beethoven!~robot-bee@c-73-65-29-166.hsd1.mn.comcast.net> has joined ##vulkan
[07:10:53] *** lpghatguy <lpghatguy!~lpghatguy@2601:642:4301:3830:f1ae:900e:76e2:1301> has quit IRC (Remote host closed the connection)
[07:14:02] *** sla_ro|master <sla_ro|master!~sla.ro@95.76.45.217> has joined ##vulkan
[07:32:55] *** rlarionov <rlarionov!~rlarionov@68-202-221-190.res.bhn.net> has joined ##vulkan
[07:34:53] *** rlarionov <rlarionov!~rlarionov@68-202-221-190.res.bhn.net> has quit IRC (Client Quit)
[07:37:39] *** rlarionov <rlarionov!~rlarionov@68-202-221-190.res.bhn.net> has joined ##vulkan
[07:38:13] *** nsf <nsf!~nsf@jiss.convex.ru> has joined ##vulkan
[07:38:23] *** rlarionov <rlarionov!~rlarionov@68-202-221-190.res.bhn.net> has quit IRC (Client Quit)
[07:44:01] *** rlarionov <rlarionov!~rlarionov@68-202-221-190.res.bhn.net> has joined ##vulkan
[07:44:15] *** rlarionov <rlarionov!~rlarionov@68-202-221-190.res.bhn.net> has quit IRC (Client Quit)
[07:46:55] *** rlarionov <rlarionov!~rlarionov@68-202-221-190.res.bhn.net> has joined ##vulkan
[07:47:08] *** rlarionov <rlarionov!~rlarionov@68-202-221-190.res.bhn.net> has quit IRC (Client Quit)
[07:48:38] *** rlarionov <rlarionov!~rlarionov@68-202-221-190.res.bhn.net> has joined ##vulkan
[07:48:56] *** MrCooper <MrCooper!~daenzer@42-144-27-164.rev.home.ne.jp> has quit IRC (Quit: MrCooper)
[07:49:13] *** rlarionov <rlarionov!~rlarionov@68-202-221-190.res.bhn.net> has quit IRC (Client Quit)
[07:50:53] *** rlarionov <rlarionov!~rlarionov@68-202-221-190.res.bhn.net> has joined ##vulkan
[07:51:29] *** rlarionov <rlarionov!~rlarionov@68-202-221-190.res.bhn.net> has quit IRC (Client Quit)
[07:58:18] *** rlarionov <rlarionov!~rlarionov@68-202-221-190.res.bhn.net> has joined ##vulkan
[07:58:31] *** rlarionov <rlarionov!~rlarionov@68-202-221-190.res.bhn.net> has quit IRC (Client Quit)
[08:18:50] *** MrCooper <MrCooper!~daenzer@42-144-27-164.rev.home.ne.jp> has joined ##vulkan
[08:26:29] <tomaka> Ralith, heh I've decided to *not* switch to opengl yet
[08:26:50] <tomaka> tried switching this morning, was too crappy, reverted the changes
[08:27:08] <Ralith> :D
[08:27:10] <Ralith> whyzat
[08:27:22] <tomaka> I had a brainfart when I looked at the code of the loading screen
[08:27:32] <tomaka> with vulkan I upload to textures while rendering the loading screen in parallel
[08:27:43] <tomaka> if I had to switch to opengl I'd need to totally rework this code
[08:28:44] <tomaka> plus the fact that I distribute tasks amongst multiple threads, including rendering tasks
[08:28:48] <tomaka> requires me to change that part too
[08:29:23] <tomaka> it might even be easier to support at the same time DX10 and Vulkan than it is to support OpenGL
[08:31:24] <Ralith> doing nice, responsive loading screens is definitely a wonderful thing
[08:32:30] <tomaka> when I play a game whose window doesn't respond during the loading screen I feel like I'm in the 90s again
[08:32:31] *** MrCooper <MrCooper!~daenzer@42-144-27-164.rev.home.ne.jp> has quit IRC (Quit: MrCooper)
[08:33:44] <Ralith> seriously
[08:34:40] <Ralith> I'm planning a VR game and it's my intention to maintain a smooth 90fps 3D scene regardless of what the engine's doing
[08:34:40] <nidefawl> I wonder if one could make a second OpenGL context for the loading screen only
[08:35:01] <tomaka> nidefawl, yes that's possible, but that's so annoying to handle
[08:35:38] <Ralith> it used to make me vaguely happy that VR was making it more difficult for people to screw that up, but now SteamVR just fudges it for you if you miss the deadline for a few frames in a row so people are going to keep being lazy
[08:35:45] *** MrCooper <MrCooper!~daenzer@42-144-27-164.rev.home.ne.jp> has joined ##vulkan
[08:36:29] <nidefawl> I heard a about problems when swapping from a different thread than the context was created on, so I was to scared to actually try
[08:38:42] <nidefawl> I saw it locking down to 45 fps a lot with SteamVR, it still requires you to deliver constant framerate
[08:39:35] *** bjz <bjz!~bjz@14.201.122.110> has joined ##vulkan
[08:40:01] <Ralith> these days it drops out to its own 3D environment and displays a "waiting for Shitty Game" message if you miss too many frames
[08:40:07] <nidefawl> But it could be my code, the box I was testing on had weird Vsync behaviour on screen too. It locked to half refreshrate if I dropped below refresh rate for a short time, it would only go back to full refresh when turning vsync off and on again
[08:40:35] <Ralith> i.e. during loading for pretty much everything
[08:42:17] <nidefawl> I saw something where you could theme that room
[08:43:31] <nidefawl> Which isn't too bad for loading screens, of course it should never ever show up while playing. For short loading screens I think its fine to use
[08:52:24] <Ralith> if it shows up it means you've already dropped too many frames in sequence
[08:53:10] <nidefawl> But you can show it in a controlled way if you want. There are methods to fade it in and out
[08:55:10] *** elect <elect!~elect@business-092-079-135-041.static.arcor-ip.net> has joined ##vulkan
[08:57:03] *** elect <elect!~elect@business-092-079-135-041.static.arcor-ip.net> has quit IRC (Read error: Connection reset by peer)
[08:57:18] <Ralith> oh, good
[08:58:02] <Ralith> still better to not hang your renderer, though
[08:58:43] <Ralith> you could do all kinds of useful stuff with that time instead; display progress if nothing else
[09:01:29] *** elect <elect!~elect@92.79.135.41> has joined ##vulkan
[09:10:21] *** neure <neure!~tsuorant@46.163.250.82> has quit IRC (Quit: Leaving)
[09:13:29] *** Neomex <Neomex!~Neomex@bvl123.neoplus.adsl.tpnet.pl> has joined ##vulkan
[09:13:43] *** realitix <realitix!~realitix@92.103.166.6> has joined ##vulkan
[09:25:03] *** tambre <tambre!~tambre@7e05-da60-b3de-657d-0e80-8a31-07d0-2001.dyn.estpak.ee> has quit IRC (Read error: Connection reset by peer)
[09:25:17] *** tambre <tambre!~tambre@7e05-da60-b3de-657d-0e80-8a31-07d0-2001.dyn.estpak.ee> has joined ##vulkan
[09:26:23] *** tambre <tambre!~tambre@7e05-da60-b3de-657d-0e80-8a31-07d0-2001.dyn.estpak.ee> has quit IRC (Read error: Connection reset by peer)
[09:26:59] *** tambre <tambre!~tambre@7e05-da60-b3de-657d-0e80-8a31-07d0-2001.dyn.estpak.ee> has joined ##vulkan
[09:29:01] *** bjz <bjz!~bjz@14.201.122.110> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[09:34:21] *** neure <neure!~tsuorant@46.163.250.82> has joined ##vulkan
[09:34:36] *** neurre <neurre!~tsuorant@46.163.250.82> has joined ##vulkan
[09:35:31] *** tambre <tambre!~tambre@7e05-da60-b3de-657d-0e80-8a31-07d0-2001.dyn.estpak.ee> has quit IRC (Read error: Connection reset by peer)
[09:36:16] *** tambre <tambre!~tambre@7e05-da60-b3de-657d-0e80-8a31-07d0-2001.dyn.estpak.ee> has joined ##vulkan
[09:37:26] *** bjz <bjz!~bjz@14-201-122-110.static.tpgi.com.au> has joined ##vulkan
[09:37:48] *** tambre <tambre!~tambre@7e05-da60-b3de-657d-0e80-8a31-07d0-2001.dyn.estpak.ee> has quit IRC (Read error: Connection reset by peer)
[09:37:57] *** tambre <tambre!~tambre@7e05-da60-b3de-657d-0e80-8a31-07d0-2001.dyn.estpak.ee> has joined ##vulkan
[09:41:42] *** MrCooper <MrCooper!~daenzer@42-144-27-164.rev.home.ne.jp> has quit IRC (Quit: MrCooper)
[09:54:32] *** ratchetfreak <ratchetfreak!c18021f8@gateway/web/freenode/ip.193.128.33.248> has joined ##vulkan
[09:59:12] *** MrCooper <MrCooper!~daenzer@42-144-27-164.rev.home.ne.jp> has joined ##vulkan
[10:01:10] *** bjz <bjz!~bjz@14-201-122-110.static.tpgi.com.au> has quit IRC (Ping timeout: 240 seconds)
[10:02:10] *** joakim <joakim!uid154127@gateway/web/irccloud.com/x-kytdbjezrnwngmye> has joined ##vulkan
[10:07:37] *** bjz <bjz!~bjz@104.222.140.98> has joined ##vulkan
[10:10:42] *** robot-beethoven <robot-beethoven!~robot-bee@c-73-65-29-166.hsd1.mn.comcast.net> has quit IRC (Quit: leaving)
[10:10:45] *** sla_ro|master <sla_ro|master!~sla.ro@95.76.45.217> has quit IRC ()
[10:12:39] *** TechnoCrunch <TechnoCrunch!~TechnoCru@101.100.137.146> has quit IRC (Read error: Connection reset by peer)
[10:14:37] *** Plagman <Plagman!~quassel@steroid.plagman.net> has quit IRC (Ping timeout: 255 seconds)
[10:16:45] *** Plagman <Plagman!~quassel@steroid.plagman.net> has joined ##vulkan
[10:28:04] *** tambre <tambre!~tambre@7e05-da60-b3de-657d-0e80-8a31-07d0-2001.dyn.estpak.ee> has quit IRC (Read error: Connection reset by peer)
[10:28:16] *** tambre <tambre!~tambre@7e05-da60-b3de-657d-0e80-8a31-07d0-2001.dyn.estpak.ee> has joined ##vulkan
[10:29:48] *** hunt <hunt!~hunt@howm/hunt> has joined ##vulkan
[10:29:50] *** tambre <tambre!~tambre@7e05-da60-b3de-657d-0e80-8a31-07d0-2001.dyn.estpak.ee> has quit IRC (Read error: Connection reset by peer)
[10:30:21] *** tambre <tambre!~tambre@7e05-da60-b3de-657d-0e80-8a31-07d0-2001.dyn.estpak.ee> has joined ##vulkan
[10:49:24] <ratchetfreak> new extensions for cross-device and cross-api communication are out
[10:51:31] <fazias> nice
[10:56:28] <ratchetfreak> the device group gives me ideas to make the SPUs of a PS3's cell processor physical devices and let them be grouped together under a single logical device
[10:57:54] *** elect <elect!~elect@92.79.135.41> has quit IRC (Read error: Connection reset by peer)
[10:58:15] *** elect <elect!~elect@business-092-079-135-041.static.arcor-ip.net> has joined ##vulkan
[10:58:46] *** ville <ville!~ville@87-93-141-3.bb.dnainternet.fi> has quit IRC (Quit:)
[11:04:19] <tomaka> ugh I didn't even notice this
[11:04:31] <tomaka> saw the 1.0.42 update but didn't realise it was so big
[11:04:51] <fazias> seems to contain all the things they will talk about at gdc
[11:06:42] <tomaka> vkCmdPushDescriptorSetKHR is interesting
[11:06:55] <fazias> so DeviceGroup is something which you can query
[11:07:05] <fazias> not define yourself
[11:07:34] <fazias> Smells like sli/crossfire
[11:09:06] <sharpneli> Damn. The push descriptorsets should've been in core.
[11:09:16] <fazias> though could be cross vendor also
[11:11:20] <tomaka> > Every physical device must be in exactly one device group.
[11:11:26] <fazias> oh, so DeviceGroup should be more or less, sli/crossfire
[11:11:47] <fazias> external memory extension seems to allow access from multiple logical devices
[11:11:50] <fazias> or instances
[11:11:53] *** kuldeep <kuldeep!~kuldeepdh@unaffiliated/kuldeepdhaka> has quit IRC (Read error: Connection reset by peer)
[11:11:54] *** kuldeep_ <kuldeep_!~kuldeepdh@unaffiliated/kuldeepdhaka> has joined ##vulkan
[11:12:07] <fazias> err, alot of things, multiple processes and/or multiple api's
[11:16:34] <ratchetfreak> it pays to skim the changelog
[11:18:14] <tomaka> if I understand correctly, the VK_KHX_device_group extension allows customizing exactly which device executes the commands and stuff
[11:18:25] <tomaka> but I suppose it's not mandatory to use it?
[11:20:06] <tomaka> oh you can know which device is executing your shader from within the shader, that's nice
[11:27:27] *** ravior <ravior!~crapitea@89.121.200.106> has joined ##vulkan
[11:28:43] <ratchetfreak> now if only there was a way to tie a vkFence to a waitable Handle of pollable fd
[11:30:14] <tomaka> isn't that what you can do?
[11:30:29] <tomaka> ah, a vkFence no, but you can with a semaphore
[11:31:38] <ratchetfreak> the semaphore handles are not waitable
[11:31:51] <ratchetfreak> as in you can't pass them to WaitMultipleObjects
[11:32:52] <sharpneli> That's CPU sync point in anycase so you can do it already now
[11:33:14] <sharpneli> As in wait for a vkFence and then trigger the windows fence
[11:33:27] *** Kingsquee <Kingsquee!~kingsley@d172-218-58-109.bchsia.telus.net> has quit IRC (Quit: https://i.imgur.com/qicT3GK.gif)
[11:33:53] *** xkpe_ is now known as xkpe
[11:33:54] <ratchetfreak> but I mean that you can't make a single thread wait for both a async file IO to complete OR a vkFence to trigger
[11:34:12] <ratchetfreak> currently it's one or the other
[11:34:16] *** BearishMushroom <BearishMushroom!~BearishMu@90-231-174-194-no159.tbcn.telia.com> has joined ##vulkan
[11:35:28] <sharpneli> You can make a second thread that does the triggering for the thread that waits for either
[11:37:31] <Ralith> you can, but it is unfortunate that you must
[11:42:39] *** HuntsMan <HuntsMan!~hunts@cpc104822-sgyl39-2-0-cust136.18-2.cable.virginm.net> has quit IRC (Quit: Konversation terminated!)
[11:54:02] *** rlarionov2 <rlarionov2!~rlarionov@68-202-221-190.res.bhn.net> has joined ##vulkan
[11:54:06] *** rlarionov2 <rlarionov2!~rlarionov@68-202-221-190.res.bhn.net> has quit IRC (Read error: Connection reset by peer)
[11:55:05] *** slidercrank <slidercrank!~slidercra@unaffiliated/slidercrank> has quit IRC (Quit: Leaving)
[11:56:03] *** mflow <mflow!~tty@unaffiliated/shiningthrough> has joined ##vulkan
[11:57:08] *** rlarionov <rlarionov!~rlarionov@68-202-221-190.res.bhn.net> has joined ##vulkan
[11:57:45] *** rlarionov <rlarionov!~rlarionov@68-202-221-190.res.bhn.net> has left ##vulkan
[12:05:32] *** kai_w <kai_w!~kjw53@global-185-24.nat-2.net.cam.ac.uk> has joined ##vulkan
[12:13:34] *** HuntsMan <HuntsMan!~hunts@dhcp9.eps.hw.ac.uk> has joined ##vulkan
[12:14:27] *** neurre <neurre!~tsuorant@46.163.250.82> has quit IRC (Ping timeout: 260 seconds)
[12:14:27] *** neure <neure!~tsuorant@46.163.250.82> has quit IRC (Ping timeout: 260 seconds)
[12:21:54] *** ville <ville!~ville@178-55-213-15.bb.dnainternet.fi> has joined ##vulkan
[12:34:44] *** jkilpatr <jkilpatr!~jkilpatr@2602:30a:c7da:b600:1202:b5ff:fe3b:d41d> has quit IRC (Ping timeout: 240 seconds)
[12:35:58] <tomaka> oh I guess VK_EXT_discard_rectangles exists so that you can ask one physical device to render some part of the image, and another physical device to render the rest
[12:36:25] <tomaka> I have no idea how the hardware works, but this seems like a weird way to expose this functionnality
[12:36:41] <Yaniel> for picture-in-picture functionality?
[12:37:20] <tomaka> I was thinking the left and right halfs of the image
[12:37:46] <Yaniel> that could be too
[12:42:10] <ratchetfreak> when you have an overlay of some kind and don't want to spend energy rendering certain parts
[12:42:53] *** neure <neure!~tsuorant@46.163.250.82> has joined ##vulkan
[12:48:55] *** neurre <neurre!~tsuorant@46.163.250.82> has joined ##vulkan
[12:52:24] *** neure <neure!~tsuorant@46.163.250.82> has quit IRC (Ping timeout: 260 seconds)
[12:58:10] *** elect <elect!~elect@business-092-079-135-041.static.arcor-ip.net> has quit IRC (Read error: Connection reset by peer)
[12:58:32] *** elect <elect!~elect@business-092-079-135-041.static.arcor-ip.net> has joined ##vulkan
[13:02:09] *** jkilpatr <jkilpatr!jkilpatr@nat/redhat/x-lnwiuensdfnxanhy> has joined ##vulkan
[13:09:46] <tomaka> it's interesting ; you have a new flag to memory heaps
[13:10:15] <tomaka> when you allocate memory from memory with this flag, it allocates one chunk for each physical device in the group if I understand correctly
[13:10:40] <tomaka> ah no, you choose which devices to allocate to
[13:10:47] <sharpneli> Yap. Same with binding etc.
[13:10:56] *** echotangoecho <echotangoecho!~echotango@dhcp-089-098-177-067.chello.nl> has joined ##vulkan
[13:14:30] <tomaka> That's really interesting, if you execute a vkCopyBufferToImage command on multiple devices, they will each copy to their own local version
[13:15:40] <fazias> sounds more and more like sli/crossfire
[13:16:36] <tomaka> and I suppose you must take care not to execute a command on multiple GPUs that modifies the same location
[13:16:43] <tomaka> because that'd be a data race
[13:17:13] <fazias> depends what that "same location" is
[13:17:42] <tomaka> a buffer in RAM for example
[13:17:51] <fazias> they cannot touch others buffers
[13:18:10] <fazias> or well, I doubt you can run compute or similar tasks over pci-e or similar
[13:19:18] <tomaka> no I mean imagine you're doing a vkCopyImageToBuffer from a per-device image to a buffer in RAM
[13:19:22] <tomaka> that would be a data race
[13:19:47] <fazias> would it be really? either it's local to local copy
[13:20:42] <fazias> I'm sure validation should catch if you somehow end up issuing a copy from local to local AND local to other gpu. I would assume that you would have to define that specifically
[13:21:04] <tomaka> also I'm wondering how exactly submitting work works with multiple gpus
[13:21:18] <tomaka> when you submit, you choose which devices execute the command buffers
[13:21:23] <fazias> well they are providing 2 ways now
[13:21:27] <fazias> multiple logical devices
[13:21:28] <tomaka> so if I understand correctly, all physical devices share the same queues?
[13:21:39] <fazias> that comminucate with externalmemory and external semaphores
[13:21:43] <fazias> or groupdevices
[13:22:05] <fazias> which sounds super like sli/crossfire, though I'm not sure on details on this one.
[13:22:55] <fazias> groupdevice with single queue means that you do same work on both gpu's but using the device id to chooce which does and what.
[13:23:07] <ratchetfreak> I'm pretty sure it's SLI/crossfire for vulkan
[13:24:27] <tomaka> oh I see, you can *export* a semaphore or a memory in a platform-independent way
[13:24:36] <tomaka> I thought it was only for interfacing with the OS
[13:24:43] <tomaka> but apparently it's also for sharing between logical devices?
[13:24:53] <ratchetfreak> sounds like it
[13:25:40] <tomaka> that's weird because you have functions to export a semaphore/memory, but no function to import them
[13:26:13] <tomaka> except in the os-specific extensions
[13:26:25] <tomaka> so I think in fact it's really just for interfacing with the OS
[13:27:38] <ratchetfreak> "To import memory created on the same underlying physical device but outside of the current Vulkan instance from a Windows handle, add a VkImportMemoryWin32HandleInfoKHX structure to the pNext chain of the VkMemoryAllocateInfo structure."
[13:27:41] *** mceier <mceier!~mceier@89-69-196-246.dynamic.chello.pl> has quit IRC (Quit: leaving)
[13:27:54] <fazias> hah, I should look for fun if I could have dx12 and vulkan both live at the same time and transfer memory between them. haha
[13:27:59] <tomaka> wait I'm stupid, you don't need to import something you exported
[13:28:13] <tomaka> since you have the handle already
[13:28:15] <fazias> Since I already merged my vulkan and dx12 binaries.
[13:28:24] <fazias> funky
[13:28:41] <ratchetfreak> fazias: you can, and you can sync against the DX12 fences with vulkan
[13:29:13] <fazias> :D if crazy enough, I could just transfer between api's also
[13:29:52] <fazias> or I mean, switch between which one is the active one.
[13:30:27] <ratchetfreak> oh you mean who does the buffer swap?
[13:31:01] *** mceier <mceier!~mceier@89-69-196-246.dynamic.chello.pl> has joined ##vulkan
[13:31:35] <fazias> actual realtime switch between which submits the commandbuffers and swaps. Not really doing, sounds just too much work unless I happen to write rest of my abstraction well enough.
[13:32:00] <tomaka> vulkan says "you shall not create a swapchain from a surface associated with another graphical api"
[13:32:00] <ratchetfreak> you can only have a single api do the bufferswap though
[13:32:11] <ratchetfreak> unless you have 2 windows and switch which is visible...
[13:32:15] <fazias> yeah, my only problem is how I recreate the window
[13:32:19] <fazias> :)
[13:32:39] <ratchetfreak> or have 2 windows, one with a vulkan swapchain and one with a DX12 swapchain
[13:32:40] <fazias> I haven't really delved on how window handles work on windows.
[13:33:01] <tomaka> it's an opaque handle to spaghetti code
[13:33:04] <fazias> Interesting extensions non the less.
[13:33:07] <ratchetfreak> they are basically drawable surfaces on which you can get events
[13:34:29] <ratchetfreak> just about every opengl example code makes a custom window "class" that does nothing even though I'm sure there is a built in one that also does nothing
[13:34:59] <tomaka> the window class is necessary in order to set the events callback
[13:35:44] <tomaka> basically the idea is that you have classes (like "button", "text", etc.) and each class is supposed to draw itself
[13:35:52] <tomaka> and to handle its own layout
[13:36:11] <tomaka> since you want to do that in your application in your own unique way, you also need your own class
[13:36:57] <fazias> I guess my question is more or less, what do I need to do If I want to close the window and give that window handle to vulkan for it's window.
[13:37:26] <ratchetfreak> yeah I figured something like that was going on
[13:37:29] <fazias> or say: I have DX12 swapchain to window, I want to destroy this and create vulkan.
[13:37:52] <ratchetfreak> there is nothing stopping you from having 2 windows
[13:38:00] <ratchetfreak> one for DX12 and one for vulkan
[13:38:09] <ratchetfreak> and then share memory between them
[13:39:30] <fazias> Sure, that's one thing that might be interesting to do anyway.
[13:40:00] <fazias> as I do have a machine where I could just give different device vulkan and dx12 and let them render side-by-side the same things.
[13:40:34] <fazias> I'll just figure out the single window case as soon as I copy&paste/rewrite my swapchain code for both.
[13:41:40] *** discoloda <discoloda!~vincent@192.241.210.244> has quit IRC (Ping timeout: 256 seconds)
[13:41:45] <ratchetfreak> but you may end up bumping into a win32 issue where you can only set the pixel layout of a window exactly once
[13:42:08] <ratchetfreak> (the core reason why a dummy opengl context is necessary)
[13:42:54] <fazias> O.o I'm not sure if vulkan/dx12 is affected by that, also because I'm directly writing win32 so I assume I can just sidestep that correctly.
[13:43:39] <fazias> My main problem is that I haven't looked up, what is actually required to have 2 independent window's and how the inputs and events are handled in those.
[13:45:12] <fazias> Anyway, those are problems I can just google up. not related to vulkan.
[13:50:53] *** Neomex <Neomex!~Neomex@bvl123.neoplus.adsl.tpnet.pl> has quit IRC (Read error: Connection reset by peer)
[13:55:05] <ratchetfreak> every message you get from peekMessage includes the windows handle
[13:58:19] <tomaka> I'm really disappointed ; since the device mask is a 32bits integer, that means you can only connect 32 GPUs together and use them with vulkan
[13:58:26] <tomaka> if I buy 33 GPUs I'm screwed
[13:59:17] <ratchetfreak> make an issue?
[13:59:38] <tomaka> I'll make one if I decide to buy 33 GPUs
[13:59:54] <ratchetfreak> if someone ever makes a massive server farm with a vulkan front-end he'll need that
[14:00:03] <ratchetfreak> *render farm
[14:00:07] <echotangoecho> why would someone do that though?
[14:00:17] <echotangoecho> OpenCL is better geared towards that purpose
[14:00:42] <ratchetfreak> built in rasterization?
[14:00:53] <echotangoecho> (if only some vendor would upgrade their opencl support)
[14:01:22] <echotangoecho> yeah but when you're rasterizing you usually don't use that many gpus ;)
[14:02:13] <ratchetfreak> when offline rasterizing 60fps for a feature length movie at 4k you will want to have as much horsepower as you can handle
[14:02:38] <echotangoecho> I don't think anyone really uses rasterization as provided by gpus in movies
[14:03:56] <echotangoecho> (and if they do, they probably don't need more than 32 gpus either on one single cluster)
[14:04:34] *** GMpow2 <GMpow2!~5@ip4d16fc2f.dynamic.kabel-deutschland.de> has joined ##vulkan
[14:05:34] <tomaka> "they probably don't need" is really not a great reason
[14:05:50] <tomaka> remember "nobody needs more than 2 MB of RAM", or something like that
[14:06:02] <echotangoecho> well, there is no reason at present someone would use vulkan on 32+ GPUs
[14:06:43] <echotangoecho> but that could change, indeed
[14:08:16] *** doomlord <doomlord!~textual@host86-176-242-250.range86-176.btcentralplus.com> has joined ##vulkan
[14:09:31] *** discoloda <discoloda!~vincent@192.241.210.244> has joined ##vulkan
[14:11:25] <fazias> you can always make more instances !
[14:11:31] <fazias> and get 32 more gpu's !
[14:12:38] <fazias> (32 per instance)
[14:13:46] <mceier> how about video walls - over 64-tiles would require over 32 GPUs with 2 outputs each (e.g. McCarran International Airport have 100 screens according to wikipedia) ;)
[14:15:04] <ratchetfreak> actually a tiled output is possible with another new extension
[14:15:38] <ratchetfreak> multiview
[14:23:51] *** echotangoecho <echotangoecho!~echotango@dhcp-089-098-177-067.chello.nl> has quit IRC (Quit: leaving)
[14:24:01] *** GMpow2 <GMpow2!~5@ip4d16fc2f.dynamic.kabel-deutschland.de> has quit IRC (Read error: Connection reset by peer)
[14:24:43] *** GMpow2 <GMpow2!~5@77.22.252.47> has joined ##vulkan
[14:31:23] *** bjz <bjz!~bjz@104.222.140.98> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[14:32:11] *** mrET <mrET!~vgabriel@29.red-88-26-240.staticip.rima-tde.net> has joined ##vulkan
[14:39:56] *** doomlord <doomlord!~textual@host86-176-242-250.range86-176.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[14:49:35] *** bjz <bjz!~bjz@104.222.140.98> has joined ##vulkan
[14:52:27] *** Vtec234 <Vtec234!~Vtec234@fez.tardis.ed.ac.uk> has quit IRC (Ping timeout: 240 seconds)
[14:54:56] *** Vtec234 <Vtec234!~Vtec234@fez.tardis.ed.ac.uk> has joined ##vulkan
[14:58:27] *** elect <elect!~elect@business-092-079-135-041.static.arcor-ip.net> has quit IRC (Read error: Connection reset by peer)
[14:58:43] *** elect <elect!~elect@business-092-079-135-041.static.arcor-ip.net> has joined ##vulkan
[14:59:15] *** doomlord <doomlord!~textual@host86-176-242-250.range86-176.btcentralplus.com> has joined ##vulkan
[14:59:16] *** Vtec234_ <Vtec234_!~Vtec234@fez.tardis.ed.ac.uk> has joined ##vulkan
[15:00:42] *** Vtec234 <Vtec234!~Vtec234@fez.tardis.ed.ac.uk> has quit IRC (Ping timeout: 260 seconds)
[15:13:31] *** Vtec234 <Vtec234!~Vtec234@fez.tardis.ed.ac.uk> has joined ##vulkan
[15:17:05] *** Vtec234_ <Vtec234_!~Vtec234@fez.tardis.ed.ac.uk> has quit IRC (Ping timeout: 268 seconds)
[15:21:30] *** sla_ro|master <sla_ro|master!~sla.ro@95.76.45.217> has joined ##vulkan
[15:36:16] *** bjz <bjz!~bjz@104.222.140.98> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[15:38:39] *** elect_ <elect_!~elect@business-092-079-135-041.static.arcor-ip.net> has joined ##vulkan
[15:38:41] *** afl_ext <afl_ext!~afl_ext3@unaffiliated/afl-ext/x-2796036> has joined ##vulkan
[15:42:09] *** elect <elect!~elect@business-092-079-135-041.static.arcor-ip.net> has quit IRC (Ping timeout: 240 seconds)
[15:59:29] *** echotangoecho <echotangoecho!~echotango@dhcp-089-098-177-067.chello.nl> has joined ##vulkan
[16:21:33] *** mflow <mflow!~tty@unaffiliated/shiningthrough> has quit IRC ()
[16:26:18] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has joined ##vulkan
[16:40:36] *** ravior <ravior!~crapitea@89.121.200.106> has quit IRC (Quit: Konversation terminated!)
[16:41:39] *** elect_ <elect_!~elect@business-092-079-135-041.static.arcor-ip.net> has quit IRC (Ping timeout: 240 seconds)
[16:43:45] *** kuldeep__ <kuldeep__!~kuldeepdh@unaffiliated/kuldeepdhaka> has joined ##vulkan
[16:43:45] *** kuldeep__ is now known as kuldeep
[16:44:21] *** kuldeep_ <kuldeep_!~kuldeepdh@unaffiliated/kuldeepdhaka> has quit IRC (Read error: Connection reset by peer)
[16:50:45] *** nsf <nsf!~nsf@jiss.convex.ru> has quit IRC (Quit: WeeChat 1.7)
[16:55:40] *** tacchinotacchi <tacchinotacchi!~tacchinot@net-93-151-149-64.cust.dsl.teletu.it> has quit IRC (Remote host closed the connection)
[17:01:44] *** ratchetfreak <ratchetfreak!c18021f8@gateway/web/freenode/ip.193.128.33.248> has quit IRC (Ping timeout: 260 seconds)
[17:03:53] *** mrET <mrET!~vgabriel@29.red-88-26-240.staticip.rima-tde.net> has quit IRC (Quit: Leaving)
[17:05:25] *** mflow <mflow!~tty@unaffiliated/shiningthrough> has joined ##vulkan
[17:39:56] *** echotangoecho <echotangoecho!~echotango@dhcp-089-098-177-067.chello.nl> has quit IRC (Quit: leaving)
[17:45:35] *** kdub <kdub!~kdub@cpe-76-167-120-4.san.res.rr.com> has joined ##vulkan
[18:13:25] *** kdub <kdub!~kdub@cpe-76-167-120-4.san.res.rr.com> has quit IRC (Quit: Leaving)
[18:14:54] *** afl_ext <afl_ext!~afl_ext3@unaffiliated/afl-ext/x-2796036> has quit IRC (Quit: Leaving)
[18:17:15] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-82s3g7l9r42569r41f4.18120a2.ip6.access.telenet.be> has joined ##vulkan
[18:19:33] *** rlarionov <rlarionov!~rlarionov@68-202-221-190.res.bhn.net> has joined ##vulkan
[18:22:47] *** ector <ector!~asdf@37-247-11-157.customers.ownit.se> has joined ##vulkan
[18:23:44] *** rlarionov <rlarionov!~rlarionov@68-202-221-190.res.bhn.net> has quit IRC (Ping timeout: 240 seconds)
[18:37:17] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-82s3g7l9r42569r41f4.18120a2.ip6.access.telenet.be> has quit IRC (Read error: Connection reset by peer)
[18:37:42] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-82s3g7l9r42569r41f4.18120a2.ip6.access.telenet.be> has joined ##vulkan
[18:38:12] *** HuntsMan <HuntsMan!~hunts@dhcp9.eps.hw.ac.uk> has quit IRC (Ping timeout: 260 seconds)
[18:40:35] *** nsf <nsf!~nsf@jiss.convex.ru> has joined ##vulkan
[18:40:44] *** joakim <joakim!uid154127@gateway/web/irccloud.com/x-kytdbjezrnwngmye> has quit IRC (Ping timeout: 240 seconds)
[18:41:03] *** joakim <joakim!uid154127@gateway/web/irccloud.com/x-hufvbvervskuacjd> has joined ##vulkan
[18:45:34] *** AncientAmateur <AncientAmateur!~ancientam@pool-74-104-161-67.bstnma.fios.verizon.net> has joined ##vulkan
[18:56:04] *** realitix <realitix!~realitix@92.103.166.6> has quit IRC (Quit: Leaving)
[18:57:08] *** tacchinotacchi <tacchinotacchi!~tacchinot@net-93-151-149-64.cust.dsl.teletu.it> has joined ##vulkan
[18:58:53] *** kai_w <kai_w!~kjw53@global-185-24.nat-2.net.cam.ac.uk> has quit IRC (Quit: WeeChat 1.6)
[19:14:00] *** echotangoecho <echotangoecho!~echotango@dhcp-089-098-177-067.chello.nl> has joined ##vulkan
[19:28:41] *** tacchinotacchi <tacchinotacchi!~tacchinot@net-93-151-149-64.cust.dsl.teletu.it> has quit IRC (Remote host closed the connection)
[19:32:07] *** AncientAmateur <AncientAmateur!~ancientam@pool-74-104-161-67.bstnma.fios.verizon.net> has quit IRC ()
[19:38:14] *** echotangoecho <echotangoecho!~echotango@dhcp-089-098-177-067.chello.nl> has quit IRC (Quit: leaving)
[19:39:41] *** HuntsMan <HuntsMan!~hunts@cpc104822-sgyl39-2-0-cust136.18-2.cable.virginm.net> has joined ##vulkan
[19:41:18] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-82s3g7l9r42569r41f4.18120a2.ip6.access.telenet.be> has quit IRC (Read error: Connection reset by peer)
[19:41:44] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-82s3g7l9r42569r41f4.18120a2.ip6.access.telenet.be> has joined ##vulkan
[19:43:25] *** kuldeep_ <kuldeep_!~kuldeepdh@unaffiliated/kuldeepdhaka> has joined ##vulkan
[19:45:47] *** jkilpatr <jkilpatr!jkilpatr@nat/redhat/x-lnwiuensdfnxanhy> has quit IRC (Ping timeout: 252 seconds)
[19:46:34] *** kuldeep <kuldeep!~kuldeepdh@unaffiliated/kuldeepdhaka> has quit IRC (Ping timeout: 264 seconds)
[19:54:16] *** derhass <derhass!~derhass@ipservice-092-216-126-046.092.216.pools.vodafone-ip.de> has joined ##vulkan
[19:58:29] *** echotangoecho <echotangoecho!~echotango@dhcp-089-098-177-067.chello.nl> has joined ##vulkan
[19:59:42] *** jkilpatr <jkilpatr!jkilpatr@nat/redhat/x-cdlforpkbzzgiuxe> has joined ##vulkan
[20:30:24] *** joakim <joakim!uid154127@gateway/web/irccloud.com/x-hufvbvervskuacjd> has quit IRC (Ping timeout: 240 seconds)
[20:30:42] *** joakim <joakim!uid154127@gateway/web/irccloud.com/x-thopklphdvjsaqby> has joined ##vulkan
[20:43:58] *** rlarionov <rlarionov!~rlarionov@node41.seg212.ucf.edu> has joined ##vulkan
[20:58:26] *** bjz <bjz!~bjz@104.222.140.48> has joined ##vulkan
[20:59:25] *** rlarionov <rlarionov!~rlarionov@node41.seg212.ucf.edu> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
[21:01:12] *** john3 <john3!~john@host86-143-90-12.range86-143.btcentralplus.com> has quit IRC (Ping timeout: 260 seconds)
[21:02:14] *** Guest97756 <Guest97756!~toor@76.ip-51-254-204.eu> has quit IRC (Read error: Connection reset by peer)
[21:02:24] *** toor_ <toor_!~toor@76.ip-51-254-204.eu> has joined ##vulkan
[21:02:37] *** kenzierocks <kenzierocks!~kenzieroc@yes.quite.indeed.old.chap.it.is.kenzierocks.me> has quit IRC (Ping timeout: 255 seconds)
[21:05:49] *** rlarionov <rlarionov!~rlarionov@node41.seg212.ucf.edu> has joined ##vulkan
[21:17:25] *** rlarionov <rlarionov!~rlarionov@node41.seg212.ucf.edu> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
[21:20:21] *** kenzierocks <kenzierocks!~kenzieroc@yes.quite.indeed.old.chap.it.is.kenzierocks.me> has joined ##vulkan
[21:22:50] *** kenzierocks <kenzierocks!~kenzieroc@yes.quite.indeed.old.chap.it.is.kenzierocks.me> has quit IRC (Read error: Connection reset by peer)
[21:25:15] *** cjhowe <cjhowe!~cjhowe@n2d035fda.cns.vt.edu> has joined ##vulkan
[21:30:21] *** kenzierocks <kenzierocks!~kenzieroc@yes.quite.indeed.old.chap.it.is.kenzierocks.me> has joined ##vulkan
[21:34:34] *** bjz <bjz!~bjz@104.222.140.48> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[21:35:37] *** begui_ <begui_!~bj@50-89-1-110.res.bhn.net> has quit IRC (Ping timeout: 260 seconds)
[21:42:51] *** sla_ro|master <sla_ro|master!~sla.ro@95.76.45.217> has quit IRC ()
[21:43:49] *** cjhowe <cjhowe!~cjhowe@n2d035fda.cns.vt.edu> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
[21:51:36] *** begui <begui!~bj@50-89-1-110.res.bhn.net> has joined ##vulkan
[21:52:27] *** jkilpatr <jkilpatr!jkilpatr@nat/redhat/x-cdlforpkbzzgiuxe> has quit IRC (Ping timeout: 240 seconds)
[21:58:20] *** bjz <bjz!~bjz@104.222.140.128> has joined ##vulkan
[22:00:04] *** [xyzzy] <[xyzzy]!~xyzzy@2600:8803:e400:d600:cc05:33f1:5374:3586> has quit IRC (Ping timeout: 259 seconds)
[22:00:54] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has quit IRC (Quit: Leaving)
[22:01:18] *** jkilpatr <jkilpatr!jkilpatr@nat/redhat/x-qojcyvpdhhevzgep> has joined ##vulkan
[22:06:15] *** _28_ria <_28_ria!~igoryonya@opfr028.ru> has quit IRC (Read error: Connection reset by peer)
[22:07:29] *** _28_ria <_28_ria!~igoryonya@opfr028.ru> has joined ##vulkan
[22:08:07] *** [xyzzy] <[xyzzy]!~xyzzy@2600:8803:e400:d600:21e:6ff:fecc:bedc> has joined ##vulkan
[22:08:11] *** _28_ria <_28_ria!~igoryonya@opfr028.ru> has quit IRC (Read error: Connection reset by peer)
[22:08:24] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-82s3g7l9r42569r41f4.18120a2.ip6.access.telenet.be> has quit IRC (Read error: Connection reset by peer)
[22:08:49] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-82s3g7l9r42569r41f4.18120a2.ip6.access.telenet.be> has joined ##vulkan
[22:17:31] *** _28_ria <_28_ria!~igoryonya@opfr028.ru> has joined ##vulkan
[22:21:38] *** _28_ria <_28_ria!~igoryonya@opfr028.ru> has quit IRC (Read error: Connection reset by peer)
[22:22:57] *** _28_ria <_28_ria!~igoryonya@opfr028.ru> has joined ##vulkan
[22:23:02] *** cjhowe <cjhowe!~cjhowe@c-71-62-157-162.hsd1.va.comcast.net> has joined ##vulkan
[22:25:01] *** rlarionov <rlarionov!~rlarionov@node14.seg212.ucf.edu> has joined ##vulkan
[22:25:30] *** bjz <bjz!~bjz@104.222.140.128> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[22:26:57] *** _28_ria <_28_ria!~igoryonya@opfr028.ru> has quit IRC (Read error: Connection reset by peer)
[22:28:19] *** _28_ria <_28_ria!~igoryonya@opfr028.ru> has joined ##vulkan
[22:28:54] *** _28_ria <_28_ria!~igoryonya@opfr028.ru> has quit IRC (Read error: Connection reset by peer)
[22:46:43] *** rlarionov <rlarionov!~rlarionov@node14.seg212.ucf.edu> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
[22:46:51] *** yong <yong!~vayne@pD9E4462F.dip0.t-ipconnect.de> has joined ##vulkan
[22:53:12] <yong> Why does Vulkan use CPU blit instead of GPU blit in windowed mode? Is that just an implementation bug?
[22:53:46] *** tambre <tambre!~tambre@7e05-da60-b3de-657d-0e80-8a31-07d0-2001.dyn.estpak.ee> has quit IRC (Ping timeout: 255 seconds)
[22:54:15] <ratchetfreak> when presenting?
[22:54:38] <ratchetfreak> I'm pretty sure that the gpu can blit to the frontbuffer just fine
[22:57:09] <chrisf> what your driver's wsi implementation, or your compositor happen to do is outside the scope of vulkan...
[23:06:34] *** _28_ria <_28_ria!~igoryonya@opfr028.ru> has joined ##vulkan
[23:07:04] <yong> ratchetfreak: Yes, when presenting. I've just looked at the output of presentmon for the lunar sdk cube.exe, and it's using CPU blit instead of GPU blit for some reason (default for d3d11 is gpu blit, or flip if it's available and you use the right flags)
[23:07:50] <yong> So I'm wondering why that's the case, if that is part of the vulkan implementation, or if that's just Microsoft being... Microsoft chrisf
[23:09:14] *** echotangoecho <echotangoecho!~echotango@dhcp-089-098-177-067.chello.nl> has quit IRC (Quit: leaving)
[23:11:17] <yong> Because if it is actually using the CPU to copy the data, as in getting it from the GPU, and then sending it back to it when composing, that seems like it could actually have a performance impact
[23:13:06] *** rlarionov <rlarionov!~rlarionov@node22.seg212.ucf.edu> has joined ##vulkan
[23:26:16] *** rlarionov <rlarionov!~rlarionov@node22.seg212.ucf.edu> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
[23:40:43] *** Kingsquee <Kingsquee!~kingsley@d172-218-58-109.bchsia.telus.net> has joined ##vulkan
[23:47:28] *** nsf <nsf!~nsf@jiss.convex.ru> has quit IRC (Quit: WeeChat 1.7)
[23:56:19] *** jkilpatr <jkilpatr!jkilpatr@nat/redhat/x-qojcyvpdhhevzgep> has quit IRC (Ping timeout: 268 seconds)
top

   February 27, 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 | >