Hacker Neue

Preferences
m-schuetz parent
AMD, do support for NV_shader_buffer_load next! Shader Buffer Load brought "Buffer Device Address" / pointers to OpenGL/glsl, long before Vulkan was even a thing. It's the best thing since sliced bread, and easily lets you access all your vertex data with pointers, i.e., you don't need to bind any vertex buffers anymore. Also easily lets you draw the entire scene in a single draw call since vertex shaders can just load data from wherever the pointers lead them, e.g., it makes GLSL vertex shaders look like this:

    uniform Node* u_nodes;
    
    void main(){
    
        Node node = u_nodes[gl_DrawID];
        
        vec3 pos = node.position[gl_VertexID];
        vec2 uv  = node.uv[gl_VertexID];
    
        ...
    }
fireant
This is the real killer feature of Vulkan/DX12, it makes writing generalized renderer so much easier because you don't need to batch draw calls per vertex layout of individual meshes. Personally I use Buffer Device Address for connecting Multidraw Indirect calls to mesh definitions to materials as well.

I just wish there was more literature about this, especially about perf implications. Also synchronization is very painful, which may be why this is hard to do on a driver level inside OpenGL

fingerlocks
Maybe I’m missing something, but isn’t this the norm in Metal as well? You can bind buffers individually, or a use a single uber-buffer that all vertex shaders can access.

But I haven’t written OpenGL since Metal debuted over a decade ago.

bsder
VK_EXT_descriptor_buffer?

If you are using Slang, then you just access everything as standard pointers to chunks of GPU memory.

And it's mostly Intel and mobile dragging their feet on VK_EXT_descriptor_buffer ...

m-schuetz OP
I'm talking about OpenGL. Vulkan is too hard for my small mind to understand, so I'm still using OpenGL. And the extension that allows this in OpenGL came out in 2010, so long before Vulkan.
bsder
No one at the big companies is developing OpenGL anymore and their support for the GLSL compiler has dwindled to nothing.

If you want that extension you're going to have better luck convincing the Zink folks:

https://docs.mesa3d.org/drivers/zink.html "The Zink driver is a Gallium driver that emits Vulkan API calls instead of targeting a specific GPU architecture. This can be used to get full desktop OpenGL support on devices that only support Vulkan."

However, you're still probably going to have to come off of GLSL and use Slang or HLSL. The features you want are simply not going to get developed in the GLSL compiler at this point.

m-schuetz OP
> The features you want are simply not going to get developed in the GLSL compiler at this point.

They exist in GLSL on Nvidia devices. If other vendors refuse to implement them, then I will be an Nvidia-only developer. Fine by me. I no longer care about other vendors if they completely ignore massive quality of life features.

reactordev
This is the way
garaetjjte
You could do similar thing with SSBO, I think?
m-schuetz OP
That is for SSBOs. u_nodes is a pointer to an SSBO in this case. That SSBO then has lots of more pointers to various different SSBOs that contain the vertex data.
garaetjjte
I'm thinking of declaring array of SSBOs that contain array of data structs. Address would be represented by index of SSBO binding and offset within that buffer. Though that limits maximum number of used SSBOs within drawcall to GL_MAX_VERTEX_SHADER_STORAGE_BLOCKS.
m-schuetz OP
To my knowledge you can't have an array of SSBOs in OpenGL. You could have one SSBO for everything, but that makes other things very difficult, like how to deal with dynamically growing scenes, loading and unloading models, etc.
garaetjjte
From https://registry.khronos.org/OpenGL/extensions/ARB/ARB_shade...:

   (3) "Do we allow arrays of shader storage blocks?

        RESOLVED:  Yes; we already allow arrays of uniform blocks, where each
        block instance has an identical layout but is backed by a separate
        buffer object.  It seems like we should do this here for consistency.
PS: You could also access data through bindless textures, though you would need to deal with ugly wrappers to unpack structs from image formats.
2 More Comments →

This item has no comments currently.

Keyboard Shortcuts

Story Lists

j
Next story
k
Previous story
Shift+j
Last story
Shift+k
First story
o Enter
Go to story URL
c
Go to comments
u
Go to author

Navigation

Shift+t
Go to top stories
Shift+n
Go to new stories
Shift+b
Go to best stories
Shift+a
Go to Ask HN
Shift+s
Go to Show HN

Miscellaneous

?
Show this modal