Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Planning: Resource binding cleanup #1037

Open
floooh opened this issue Apr 29, 2024 · 0 comments
Open

Planning: Resource binding cleanup #1037

floooh opened this issue Apr 29, 2024 · 0 comments

Comments

@floooh
Copy link
Owner

floooh commented Apr 29, 2024

This would make sense after the storage-buffer update:

General idea is to allow more flexibility when mapping the sokol-gfx 'bind slot convention' to the backend API bind slots.

  • Get rid of shader stages in sg_bindings:
typedef struct sg_bindings {
    uint32_t _start_canary;
    sg_buffer vertex_buffers[SG_MAX_VERTEXBUFFER_BINDINGS];
    int vertex_buffer_offsets[SG_MAX_VERTEXBUFFER_BINDINGS];
    sg_buffer index_buffer;
    int index_buffer_offset;
    sg_image images[SG_MAX_IMAGE_BINDINGS];
    sg_sampler samplers[SG_MAX_SAMPLER_BINDINGS];
    sg_buffer storage_buffers[SG_MAX_STORAGEBUFFER_BINDINGS];
    uint32_t _end_canary;
} sg_bindings;

The sg_shader_desc needs to provide a mapping from those unified "sokol-gfx bindslots" to shader stages and (probably backend-API specific) concrete bind slots (typically generated by sokol-shdc).

  • Q: also get rid of the 'implicit' backend-specific bind slot indices? This means the sg_shader_desc bind slot-mapping needs backend-specific slot indices (which is probably more transparent to the user)

  • while at it also get rid of the stage param in sg_apply_uniforms() (and provide a mapping in sg_shader_desc instead for backends which need this)

  • TL;DR: SG_SHADERSTAGE_VS/FS should only show up in sg_shader_desc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant