`RenderingDevice.buffer_get_data` has very high latency about godot HOT 2 OPEN

I think the difference is that you are keeping the Texture in CPU accessible memory. So the data doesn't need to be copied from the GPU.

Out of curiosity, can you try creating the texture without the TEXTURE_USAGE_CPU_READ_BIT flag?

Edit: I ended up testing myself. And can confirm your results. The first run I got about 3000ms for ssboTest() and 8ms for textureTest().

Then i removed TEXTURE_USAGE_CPU_READ_BIT and it became 3000ms and 400ms respectively.

Then I swapped the order of ssboTest() and textureTest() (I called textureTest() first) and then I got 3000ms for textureTest() and 2ms for ssboTest().

Oh, and bonus, if I leave TEXTURE_USAGE_CPU_READ_BIT enabled, and have the calls swapped. Then I got 8ms for textureTest() and 3000ms for ssboTest().

So this is pretty clearly just highlighting the real cost of stalling the GPU to read back data. Whichever one does it first incurs the cost, then the second one doesn't pay for the cost because the GPU has already been stalled. If you keep your texture in CPU accessible memory, then you don't have to pay that cost, which clearly pays off.

from godot.

Doing your tests on my device gives similar results. The problem then is that there is no equivalent of TEXTURE_USAGE_CPU_READ_BIT for SSBOs exposed through the API. Comparing the source code for storage_buffer_create and texture_create, setting TEXTURE_USAGE_CPU_READ_BIT in turn sets VMA_ALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT on the driver side when allocating the texture. driver->buffer_create also has options that set this flag, but they aren't exposed by storage_buffer_create.

As an aside, there was one case where your tests produced a different result on my machine. Running textureTest() before ssboTest() with the TEXTURE_USAGE_CPU_READ_BIT enabled, I got 5us for textureTest() and 145us ssboTest(). That is, SSBO access sped up significantly, even though the GPU didn't appear to stall. EDIT: Removing the texture access entirely (that is, just creating the texture without reading from it) gives the same result. I noticed some code in the driver for pooling small allocations, so maybe the SSBO is actually reusing part of the texture's allocation.

from godot.