Gregory's Server@julienbarnoin At the point where there is a push for pointers in the shading languages, that will be the kick in the pants required
|
4 comments
@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/ |
@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.