Write only (write combined) memory

I have a chunk of write combined memory (GPU memory - though it doesn't particularly matter where it comes from other then that it is relatively large typically).

Now, because reading from this type of memory is prohibitively expensive I would like to make it impossible to read from this memory in the API that I'm building.

Because IndexMut: Index this isn't as straight forward as I would've liked it to be, what are the typical options used for this kind of scenario?

Note that IndexMut, handing out mutable references, allows reading operations as well, even if IndexMut: Index weren’t the case (you can read the value behind e.g. a &mut u8).


Yeah - that's also a pretty big problem in this case and would be another reason IndexMut wouldn't be possible here.

I wouldn't say there's anything "typical" in this situation. Reading being a lot more expensive than writing is exactly the atypical case. Thus, I don't think there's anything particularly nice or idiomatic you can do with it.

What you can do is not implement IndexMut and Index. Instead, provide a method that takes a range of addresses as a Range<usize> or even only a base address, as well as an Iterator that provides elements by-value (no references), then implement this method so that it only ever writes and never reads.

It's another motivation example for introducing &out references in addition to working with uninitialized memory. Unfortunately they didn't get much traction...

1 Like

This is way harder than it sounds, because Drop normally gets invoked whenever you write one value over the top of another:

let mut d = “first”.to_owned();
d = “second”.to_owned();

This will implicitly invoked the String destructor, so that first doesn’t leak, and this involves reading from “d” before the second one gets written to it.

1 Like

That's a good point, however I suspect that such Rust code isn't going to be able to run on the GPU anyway, and @Jasper-Bekkers only needs to copy over a bunch of non-Drop primitive numbers. (Is that the case?)

Yeah this would only concern POD types, so Drop shouldn't really be running any logic here.