Question Clarification on ComputeBufferMode.Immutable

Hi,

ComputeBufferMode is not really meant for external users to change. While the default value in the constructor is called Immutable the name is a huge misconception. What it actually means internally is basically as a buffer in OpenGL would work (so everything goes). The dynamic and others are for internal things, like keeping mesh in CPU accessible memory etc.

If we really twist the wording of the docs "Compute shaders and other GPU operations are allowed to modify the contents of the buffer." well, upload operation is a GPU timeline operation performed by GPU so yeah, SetData works just fine

ComputeBuffer.BeginWrite is only for the subupdates buffer mode. It's currently used by the hybrid renderer. The idea is to have mapped buffer that one can write directly into from Burst jobs, saving a memcpy. If you're not doing something like that then just the SetData is fine.

However if you do use it remember that you cannot write into an area that's still used by the GPU. And we have no way of asking from C# side if we're done with specific frame. So it will work with just pure luck.

Until we get around to actually making externally usable buffer modes, which I hope we get a chance to do sooner rather than later, it's better to just ignore the parameter and just use the default.

 

Hi,

There is a big difference with the SubUpdates buffer (not Dynamic, for most that's just a normal buffer except on D3D11) is that it's CPU mappable memory in most cases. As an example in Vulkan it's just host memory that GPU can read directly. Reading from it is slower on GPU but if you need to perform an upload every frame regardless it can make sense to use it.

Unfortunately you can't be safe with ComputeBuffer.BeginWrite at all for now. We will bring an API Sometime(tm) in the future to do the syncing, but I cannot promise anything definite. If you, and preferably many others, pester us about it enough it will tell us that there is demand for it so the priority can be raised.

SubUpdates works perfectly with D3D11, but within it's limitations. As in the only way to write into subupdates buffer is via ComputeBuffer.BeginWrite, sure on some API the SetData can work, but as we don't have a validation layer yet we can't really tell on runtime if it's accidental working or not.

 

D3D11 Dynamic becomes D3D11_USAGE_DYNAMIC which incidentally is also what SubUpdates mode becomes too on D3D11. So it's write only on CPU and read only from GPU. The dynamic was made specifically to use the D3D11 dynamic buffers. Incidentally the Immutable was made for same reason (D3D11_USAGE_IMMUTABLE) but something went wrong. It's just a naming issue that ought to be internal only but unfortunately it has leaked a bit.

1. Correct. Do note that you get Immutable if you just create a ComputeBuffer without specifying any specific mode.
2. True, it cannot even be used with SetData. Dynamic is writeonly from CPU and readonly from GPU, and SetData is essentially a GPU timeline copy. You need to map in order to write into Dynamic, which there is no other API than the BeginWrite.
3. There is no such memory in D3D11 unlike Vulkan, DX12 and Metal. But D3D11_USAGE_DYNAMIC comes the closest so it's "emulated" via that.
4. Because it's D3D11_USAGE_DYNAMIC the only way to write into it is map, thus SetData doesn't work. If we would want SetData to work we'd need to map it at SetData and then perform memcpy, meaning it would have the perf penalty of memcpy and also GPU read speed penalty, giving worst of the both worlds.
5. That is true. It's because we don't actually have a GraphicsFence that can perform CPU-GPU syncs on the public API. It's Coming(tm), but as usual I can't promise any specific timeline.
6. That is correct. But if you are willing to be brave you can try the SubUpdates and then just fingers crossed hope that perhaps 4 frames is enough buffer. Just please don't come demanding my head on a stake if it breaks :'D. And most importantly test the perf impact!
7. Yeah. That's why it's "hidden", well actually just not released yet, as it's a feature that was not exposed completely. Because the enums are not well named, and because they also give limitations, such as not being able to call SetData. Especially as we don't have any sort of validation layer yet so doing something might work on platform X by accident but break on platform Y. The default mode is guaranteed to work the same everywhere.

You are correct that the documentation is wrong. But it's not anything users are meant to change for the short term. That's why the ComputeBuffer constructor doesn't even tell that there is the secret ComputeBufferMode that can be passed there. It's not ideal but it definitely will be fixed when we get around to exposing that.

Rest assured we are well aware of these and do understand the annoyance users have with these. Personally I just hope we'd have time sooner rather than later to get around to fixing this particular can of worms.

 

Partly. On Vulkan and Metal we can give internally a guarantee that we won't go over a certain threshold (but that's subject to change and users cannot really query it so I better not say it lest people start using it locking us in). And some platforms follow the Quality settings and some don't, so it's a mess but understandable mess as it was written before any of this was even considered. On DX11 there is no real way of doing it at all, except with DX11.3 fence which is not available on any older DX11.

More frames is definitely safer, but 10 is definitely overkill and you'll likely just waste a ton of memory doing it. Even so if you do go to the unsafe territory in DX11 the only thing that happens is graphical glitches, so if you are not actually doing any gameplay or other functionality you just get some new data being used instead of old data when drawing.

But most importantly it should be profiled. If you're just doing stuff on the mainthread it's likely that you won't see much improvement if at all. The big reason why Hybrid uses the BeginWrite is because it writes from Burst jobs. And doing normal setdata would effectively serialize all that into the mainthread ruining the whole thing. So pointers are passed to jobs and they just write stuff into GPU memory. That's where you'll see some real gains. If your game can work with that (Burst is available in normal Unity and usable now) you'd likely see some major gains. Just write it considering that there will be a way to query either how many frames is safe (unlikely) or just query if certain frame is complete (more likely) and you'll be good to go when we get that part out.

 

It's partial data. But even this is already against the spec (what little spec DX11 even has). No guarantees of atomicity can be made. I would _guess_ that 32bit would be atomic, but wouldn't be too surprised if it's all just garbage.

The plan ought to be modified like this:
Write to the staging buffer using BeginWrite, issue copy to the geometry buffer, draw using that buffer, wait several frames to reuse the staging buffer. Because the copy happens on GPU timeline and that is fully synced. The unsafe part is that when GPU timeline commands are done with the data. So you need to wait for the copy command to finish in order to reuse the staging buffer.

To be super precise you don't even need to write to the staging buffer when you issue the copy command, only when the copy command is actually running on the GPU it must have been written into. But this is something that cannot be reasonably achieved in practice. So better to have the data there ready for it before you even issue the copy command.