unfortunately vulkan has no such mechanism
unfortunately vulkan has no such mechanism
Thundreds of MB per second :)
Pi'm not saying that link is how you can do it, i'm just sending that purely because it's an example of how it's done with other apis
Kin most engines you have a bunch of small tranfers, which you would typically batch & connect with semapores (or timeline sempahores if you support that) and then wait on the last one in the chain with a semaphore.
You can use events in the middle as a lightweight way of detecting that a specific transfer is done already (if you don't have timeline semaphores)
You can use events in the middle as a lightweight way of detecting that a specific transfer is done already (if you don't have timeline semaphores)
Kwell you could export a vulkan fence as win32 object and then do unholy things with it, but from the spec I don't think you're guaranteed that the returned win32 handle supports usage as a wait handle (and specifically nvidia doesn't support this apparently)
Toh no, waiting for timeline semaphores requires an extension/vk1.2
KAlso regarding transfers, that's exactly why timeline semaphores are such an amazing feature. You just make a central semaphore, and whenever you transfer something you give it an ID (by incrementing a counter) and "enqueue" the transfer task by wrapping your GPU work in a starting "wait for semaphore to be at step ID -1" and at the end you just advance the semaphore to ID.
Then you a) get free syncronization with little to no work, and you can check whether a specific transfer has completed via just "is semaphore count > ID"
AND you even get pretty realistic loading bars by just saying "start of level load was ID = 185, end of level load is ID 1835" then just poll the semaphore count and show the progress bar as
Then you a) get free syncronization with little to no work, and you can check whether a specific transfer has completed via just "is semaphore count > ID"
AND you even get pretty realistic loading bars by just saying "start of level load was ID = 185, end of level load is ID 1835" then just poll the semaphore count and show the progress bar as
(min(0, currentId - startId) / (endId - startId)) * 100
Ktimelines semaphores are a feature of the KHR sync2 extension... But if you don't support oldish devices almost all drivers have backported them as they require nearly no hardware support
Klike 40% windows support... Not great I guess, but it's a perfect opportunity for progressive enhancement imo
Kmemory transfer is pretty easy to abstract away and you can always replace the timeline semaphore with either a fence and one submission / transfer or a pair of semaphore + event / transfer (but you can batch the transfers into bigger submissions)
Tsince you seem quite knowledgeable about transfers, do you know the "correct" way to upload a lot of data quickly?
Tmy code currently maps a buffer, writes a lot to it, unmaps it, and does some copy commands
Ti am looking into persistently mapped buffers though
Tand i also abuse the graphics queue instead of using the transfer queue 
Kit depends as with anything. Most important thing is a) keep your GPU busy as always and b) use a transfer queue if you really need perf.
Nvidia drivers (used to? still do? a year ago it was this way) only use half the available PCIe bandwith with non-transfer queues.
Regarding buffers, I always went the route to have as many 1mb host-mapped buffers that as I could have or one buffer that was however big as the hardware supported (yes some platforms don't have 1mb of host-mapped space) and then used that as my hole to stuff data through. Designed everything around unblocking that buffer as soon as possible as it's the main blocker.
I think I also saw some gains on modern hardware by using larger blocks & manually invalidating data (which wastes some space but may improve throughput because the driver knows exactly what to transfer). I think I eventually moved to always manually invalidating the data range as host-coherent was often a subset of host-available and there's not much reason to make it coherent in the first place
Nvidia drivers (used to? still do? a year ago it was this way) only use half the available PCIe bandwith with non-transfer queues.
Regarding buffers, I always went the route to have as many 1mb host-mapped buffers that as I could have or one buffer that was however big as the hardware supported (yes some platforms don't have 1mb of host-mapped space) and then used that as my hole to stuff data through. Designed everything around unblocking that buffer as soon as possible as it's the main blocker.
I think I also saw some gains on modern hardware by using larger blocks & manually invalidating data (which wastes some space but may improve throughput because the driver knows exactly what to transfer). I think I eventually moved to always manually invalidating the data range as host-coherent was often a subset of host-available and there's not much reason to make it coherent in the first place
Pfwiw persistent host-mapped buffers is how directstorage works
Pit maps the memory, and then talks directly to the nvme driver and says "write directly into this memory"
Kpretty sure that is just the best way to do it these days. Unfortunately not many improvements in sub-allocation performance, which I think could be better as it hands off that coherence problem to the driver without any of the downsides that a fixed block size has
Kiirc they also have some auto uncompression stuff that can align compressed data to specific block sizes so the unpacked data fits exactly into one of their GPU transfer blocks?
Pyeah there's some opt-in stuff like that
SInteresting
Tmy code could only ever get my gtx 960M to upload at 800MB/s
SHow do you expect to show a progress bar while doing it?
SYou're manually counting this?
KI can't seem to find the spec online, what PCIe is that running on?
Tyeah i connected a voltmeter to the bus and counted every bit that passed
Tseemingly 3.0
Kjust via your normal render pipeline. You can query the progress while the GPU is doing the work. It's all atomic
Ttask manager and hwinfo usually said that i only ever utilized like 2-5% of the bus
KI'm just guessing it's using x16, so that'd put it at a max of 15.754 GB/s according to wikipedia
SFile.Open("pog.bin").CopyTo(new UnmanagedMemoryStream(mapped, len, len));
Kcan you share the transfer code? Would love to have a look at it
Ksomething like that is actually possible 
Tthat validates the readout from task manager; 800 / 0.05 = 16000
S(it's bad to distribute uncompressed resources)
Kcould throw a deflate stream in the middle don't think that'd be a problem
Kproblem is more that you'd need to build some super smart logic to automagically advance the underlying unmanaged memory stream to the right location
Kcause your resources are very likely much larger than you can fit in host-mapped memory
Tthere's nothing more to it than map, write, unmap, copycommand, submit, wait for fence
Tand the old code was so unreadable that i'm rewriting the hole thing
Kwell how big are the blocks you're copying here?
Ti was roughly doing 8MB uploads
Kand then in sequence or in parallel?
S(i meant mapped staging buffers)
Tmultiple threads were uploading constantly
Kyeah, those are often pretty limited in space
SUnless Unified memory?
K
I don't think I really understand what they are doing tbh, this should be 100% IO bound workT... aren't staging buffers just in RAM?
SExactly
Kwell it depends* they need to be in a space that the driver has access to