Gregory's ServerIt feels like the people in the best situation to address this would be the Khronos group. Sadly they seem uninterested in this, they feel like GLSL is just fine as it is and have no one working on evolving it or a next version (I asked).
Their solution seems to be to rely more and more on HLSL instead... Great. 😑
|
Top-level
5 comments
@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. Not shooting myself in the foot with it performance-wise is my job. @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). @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. @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/ |
@julienbarnoin At the point where there is a push for pointers in the shading languages, that will be the kick in the pants required