@NOTimothyLottes Well, I already use pointers in GLSL...

@NOTimothyLottes Well, I already use pointers in GLSL thanks to VK_KHR_buffer_device_address and GLSL_EXT_buffer_reference, even though they're a pain to use and limited.
I would definitely want what VCC promises - more generic and easier to use pointers, including function pointers.

Not shooting myself in the foot with it performance-wise is my job.
Writing a suboptimal GPU function can be a performance win, if it saves me a CPU/GPU roundtrip. This is my main concern.

Like 27 February at 15:20 | Open on mastodon.gamedev.place

3 comments

Julien Barnoin

@NOTimothyLottes A related missing feature in GLSL that is a pain for me is characters and string manipulation.

I don't care if it's inefficient, I want to be able to do it and save the pain of a roundtrip to setup some text to be displayed in my UI code (that is already mostly on GPU except for the text parts).

27 February at 15:25 | Open on mastodon.gamedev.place

NOTimothyLottes

@julienbarnoin I'd like code pointers, with ability to setup explicit blocks of register state. So it's possible to have functions that apply to state in registers without all the push/pop stack nonsense which would be prohibitively expensive.

27 February at 15:41 | Open on mastodon.gamedev.place

Julien Barnoin

@NOTimothyLottes Actually on my end, I'd already be happy to see just function pointer constants that could be fully inlined at compile time. This would be quite easy probably, but GLSL doesn't offer even this. Maybe with another layer of ugly macros I could make something work...

See for instance examples here: https://iquilezles.org/articles/sdfrepetition/
Every time there's an "sdf()" call represents a use for a function pointer that could be known at compile time and still make code reusable.

27 February at 15:48 | Open on mastodon.gamedev.place