Optimizing memory allocation for UMA devices.

[gabrieljemail]

Describe the request

I don't want to be this, but this is how I felt when I wrote the code behind this. I hope to help everyone here, and just improve others' code. Here is what the message is:

This is really easy to describe: you are allocating VRAM and the swapchain the standard way, but not the fast way. Here is a list of issues. I am already working on a PR since my fork already fixed all of them.

1. No UMA support: Most people using VulkanMod just to play the game are using iGPUs like Intel integrated graphics. I am sure you understand the VRAM problem here. But you use device local memory for everything instead of host visible memory for them. This causes unnecessary copying and command uploading.
2. Imprecise frame rate capping: This issue is actually a vanilla issue, but it could have been fixed. The issue is that normal thread sleep timers don't account for scheduler context switching while sleeping or just don't care if the timer is off by a couple milliseconds. The best way to fix this is to use a spin timer past a certain point. With my timing, this completely fixes frame pacing with FPS caps.
3. Inflated shader parameters: You did compress position and UV parameters for the vertex shader, which is great. But it could have been smaller without breaking the game. I managed to get it down to 14 bytes per frame.
4. Improper frame timing parameters: This one isn't as bad, but it is smoother to use more relaxed frame pacing modes with Vulkan. I used FIFO_RELAXED for VSync and MAILBOX for non-VSync, and it immediately felt smoother and didn't drop slightly off frames.
5. Individual raycasts for block entities: This is also an issue that came with vanilla and doesn't affect rendering that much by default, but it matters. In your README, you claim reduced CPU overhead. While this is true, it can be improved even further.

These seem minor, but they personally got my low-end system from 110 average FPS to 220+ average FPS, with <2ms lower frame times. I am also not including some custom batching and optimized math/raycasting, but that's because they will break most mods. Even fullbright doesn't work, so don't even ask.

[sienaiwun]

I’m curious about your claim of reducing the vertex attributes to 14 bytes per vertex.

Currently the layout I’m seeing from terrain.vsh:

layout(location = 0) in ivec4 Position; // 16 bytes
layout(location = 1) in uvec2 UV0; // 8 bytes
layout(location = 2) in uint PackedColor; // 4 bytes

This totals 28 bytes per vertex (likely 32B aligned in practice).

Could you explain how you managed to reduce this to 14 bytes without breaking the game？

[gabrieljemail]

• For position, I packed X, Y and Z into three 16-bit signed integers (short), making the whole thing 6 bytes. I then bound the pipeline attribute to VK_FORMAT_R16G16B16_SSCALED.
• For UV0, I made U and V both 16-bit unsigned integers (ushort). The pipeline attribute is VK_FORMAT_R16G16_UINT.
• For PackedColor, I kept it the same since it was already a reasonable size.

Edit: 12 bytes broke the rendering engine, but it's possible if you aren't lazy like me and you update the strides.

[sienaiwun]

I wonder if the loss of precision affects the visual quality?

[gabrieljemail]

From my testing, it has zero effect. Let me know if you see any though. I even tested on max possible settings and saw no visual difference.

[sienaiwun]

Sorry, my earlier interpretation was off.

With your actual current layout:

Position (vec4 / R16G16_UINT): XYZ are quantized (scaled by 2048 shorts), Z is also carrying encoded light info
UV (R16G16_UINT): pre-scaled UV(scaled by 32768 shorts)
Color (UNORM4x8): packed RGBA
Total: 16 bytes per vertex

Just curious how you reduce this to 14 bytes?
Also, using VK_FORMAT_R16G16B16_SSCALED directly instead of quantizing them by 2048 will reduce precision, right?

[IMS212]

Signed 16 bit integers are not enough at all to store the actual full quality chunk. Have you checked iron bars and mangrove roots if they clip into the ground?