GPUBatch VBO's as Storage Buffers #105221

New Issue

Clément Foucault · 2023-02-26T16:11:00+01:00

Clément Foucault commented

2023-02-26 16:11:00 +01:00

During the Metal Backend developpement, it was needed to provide different versions of shader programs that uses geometry shaders.

The issue is that these version requires some non-ideal modification of the backend. These geometry-shader less programs might even perform better in most cases. Moreover, having a way to arbitrarily read from vertex buffer data might become necessary for some algorithm (gpencil, curves, better attribute supports).

Because of this I propose the following approach:
Instead of this:

    /* Using the vertex input pipeline */
    .vertex_in(0, Type::VEC4, "pos")

a shader needing arbitrary access would declare this in its create info.

    /* Using the SSBO pipeline */
    .storage_buf(0, Qualifier::READ, "vec4", "pos[]", Frequency::GEOMETRY)

The important bit here is Frequency::GEOMETRY.

Every storage_buf tagged with Frequency::GEOMETRY would have an automatically matched VBO attribute (matched by name) bound to them. The GPUBatch binding (or drawing) routine would be responsible for this. Limiting that to a GPUBatch feature might require some refactor of code using no_geom shader with GPU_immediate.h.

This is a bit abusing the Frequency to tag these but I think it's an ok thing to do. Maybe rename Frequency::BATCH to Frequency::OBJECT and use Frequency::BATCH instead or Frequency::GEOMETRY.

A missing SSBO bind would become an error in this case. No default binding would be provided. Note that this could be relaxed later on for attributes. But nowadays, the no_geom shaders mostly use attributes that are required to exists.

Another issue is that attributes have stride and offset.

I propose for the simplicity of the implementation to not support attributes that are interleaved. Maybe some will need to be split into different VBOs or use GPU_vertformat_deinterleave.
Offset can easily be replaced by the SSBO binding offset (see: glBindBufferRange doc).

During the Metal Backend developpement, it was needed to provide different versions of shader programs that uses geometry shaders. The issue is that these version requires some non-ideal modification of the backend. These geometry-shader less programs might even perform better in most cases. Moreover, having a way to arbitrarily read from vertex buffer data might become necessary for some algorithm (gpencil, curves, better attribute supports). Because of this I propose the following approach: Instead of this: ``` /* Using the vertex input pipeline */ .vertex_in(0, Type::VEC4, "pos") ``` a shader needing arbitrary access would declare this in its create info. ``` /* Using the SSBO pipeline */ .storage_buf(0, Qualifier::READ, "vec4", "pos[]", Frequency::GEOMETRY) ```` The important bit here is `Frequency::GEOMETRY`. Every `storage_buf` tagged with `Frequency::GEOMETRY` would have an automatically matched VBO attribute (matched by name) bound to them. The `GPUBatch` binding (or drawing) routine would be responsible for this. Limiting that to a `GPUBatch` feature might require some refactor of code using no_geom shader with `GPU_immediate.h`. This is a bit abusing the `Frequency` to tag these but I think it's an ok thing to do. Maybe rename `Frequency::BATCH` to `Frequency::OBJECT` and use `Frequency::BATCH` instead or `Frequency::GEOMETRY`. A missing SSBO bind would become an error in this case. No default binding would be provided. Note that this could be relaxed later on for attributes. But nowadays, the no_geom shaders mostly use attributes that are required to exists. Another issue is that attributes have stride and offset. - I propose for the simplicity of the implementation to not support attributes that are interleaved. Maybe some will need to be split into different VBOs or use `GPU_vertformat_deinterleave`. - Offset can easily be replaced by the SSBO binding offset (see: `glBindBufferRange` [doc](https://registry.khronos.org/OpenGL-Refpages/gl4/html/glBindBufferRange.xhtml)).

Clément Foucault added the

Type

Design

label 2023-02-26 16:11:00 +01:00

Clément Foucault added this to the EEVEE & Viewport project 2023-02-26 16:11:01 +01:00

Clément Foucault commented

2023-02-27 12:13:23 +01:00

Tag @Jeroen-Bakker @Michael-Parkin-White-Apple

Clément Foucault added the

Module

EEVEE & Viewport

label 2024-02-26 14:21:40 +01:00