it maps the memory, and then talks directly to the nvme driver and says "write directly into this me
it 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
Kand on integrated GPUs that can get pretty funky
Tmost of the time on the profiler was being spent in copying to mapped memory
KI mean many of the modern AMD cards have a memory type that looks like
with like 8GB
but on some iGPUs the best you get is
at very limited space
with like 8GB
but on some iGPUs the best you get is
at very limited space
Khmm. Could be related to it being coherent if the implementation is weird how are you copying?
how are you copying?TUnsafe.CopyBlockUnaligned :)
Ti tried a normal for-loop but it was slightly slower
KI'm not sure, but can you try using Span.CopyTo? pretty sure that is the fastest you can get
Kcause that uses fancy vector instructions and stuffs
Twas the same speed as Unsafe.CopyBlockUnaligned
Kah ok :(
SI think they call same underlying method with
ref bytemaybe they unified those two at some point, I think I heard about that
Khmmm
KFuck it, let me create a project
KI wanted to rewrite type references today but I guess I'm torturing my GPU today
KHaven't really build stuff with the new(ish) chain extensions, and man that opens up some awesome uses that I didn't even think of when this was designed: