Document binding a RDUniform to a particular mipmap level

[blackears]

Describe the project you are working on

A volumetric data viewer that uses compute shaders.

Describe the problem or limitation you are having in your project

Godot currently does not have a way to bind a specific mipmap level to a shader input slot. This is necessary to let you target a particular mipmap with reading or writing. I need to be able to do this because I've developed a shader that calculates a gradient from a source image, and I need to run through every mipmap level in my texture and apply it to each level (so I can create an output texture that is the gradient of my input texture at all mipmap levels). At the moment I'm only able to use it on the base level map.

The OpenGL standard provides a way to do this with methods like:
void glFramebufferTexture(GLenum target, GLenum attachment, GLuint texture, GLint level);

I'm not sure what the best way would be to add this to Godot, but adding an extra field to RDUniform to specify the mipmap level seems like the most logical place for me.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

If I could specify a mipmap level, I could compute the mipmaps of my target texture by just running my computer shadere on each mipmap level. At the moment it looks like I need to do a work around by dumping the texture to the CPU so I can do each mipmap level individually.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

Add an extra field to RDUniform that specifies a mipmap level to be bound to glsl image2D and image3D slots.

If this enhancement will not be used often, can it be worked around with a few lines of script?

The work around involves dumping image data to the CPU which is very slow.

Is there a reason why this should be core and not an add-on in the asset library?

Requires changing how RenderingServer works.

[ze2j]

It's already possible to bind a particular mipmap level (and a layer too).

The trick is to create a shared texture with rd.texture_create_shared_from_slice() and bind the returned RID to the compute shader as usual. A shared texture is a kind of proxy (or view) of the original one. It does not duplicate data on GPU.

This is well explained in a recent progress report where I also discovered this feature. The concept of shared textures would deserve some explanations in the RenderingDevice documentation as it's seems to be a Godot specific feature and not a common "knowledge of modern graphics APIs". Moreover the current documentation is wrong because the method works on most types of textures (I tested it myself).

[clayjohn]

it's seems to be a Godot specific feature and not a common "knowledge of modern graphics APIs"

Its actually a core concept in all modern GPU APIs, under the hood in Vulkan, it is using an ImageView. Which is exactly what you described as a shared texture.

I agree that this is a documentation issue as reading from a specific mip level is possible now, but the API documentation is pretty sparse so its hard to learn how to do it.