Reconsider supporting calling gpu-funcs that take uniforms from other gpu-funcs

[cbaggers]

Had great chat with krwq on the subject, I mentioned that I hadnt wanted this behaviour initially and then we had this discussion

01:08 Baggers: Thanks! Why is it not intended to work? 01:09 Baggers: (I'm fine with that but just would like to understand) 01:09 <Baggers> just as I didnt think that was the right way at the time :/ not a great answer but I cant recall my reasoning on it sadly 01:10 Baggers: Reconsider please - currently shaders look awkward in some places :-) (I'm doing shadertoy kinds of stuff where you draw on a quad right now and time is pretty useful everywhere) 01:12 Baggers: also got one piece of feedback about def-simple-main-loop - when you define more than one loop and :start another after starting the first one it says it is already running - would be nice if it auto-stopped the old one for you 01:13 <Baggers> but what happens if a function has a uniform that isnt in the callers signature? does it append itself to the stages uniform list? what if two are used with the same name but different types? what if they are passed as first class function? etc. Lots to think about. The 'factor out to dedicated functions is much cleaner'. Also the calling syntax from map-g is to treat them as keyword arguments, maybe that should be 01:13 <Baggers> the case in gpu-funcs too. 01:13 Baggers: I would start with the error and wait for issues about it 01:14 Baggers: so the same signatures with missing acceptable 01:14 Baggers: I mean if you define 10 uniforms and define shader with 9 but signatures the same that would beok 01:14 Baggers: that would work for most of the people I hope :) 01:20 <Baggers> maybe. I'm still not a fan though. if func A has a time uniform and so does function B that A calls. then all is ok. But then later on the user decides they dont need to use time in A and so they remove the uniform. Now it complains that time is missing. We can easily explain that function B needed time but it's a bit gross to have silent dependencies like that. However if C is created that takes time as an argument 01:20 <Baggers> and A & B call C then then problem never exists and refactoring is smoother as the dependencies are visible in the code itself 01:23 Baggers: In my eyes it feels like it should work like this: I define func a and b with whatever args and uniforms I call b in func a and do not care about any uniforms (I mean that b's uniform don't have to be subset of a) - when you compile the shader and some uniforms don't match I get an error 01:24 Baggers: all shaders' uniforms together should be a subset of whatever I pass to the pipeline 01:25 Baggers: as a thing nice to have would be detecting early that some uniforms types do not match when calling b in a 01:25 Baggers: but optional - as long as I get actionable error it's ok 01:25 Baggers: does that sound reasonable? 01:27 Baggers: you got broader perspective on the problem I still got intuiteveness of newbie to the framework so just giving some perspective :) 01:27 <Baggers> krwq: thanks I really appreciate it. Its ncie to think through this stuff again 01:28 Baggers: I really like this project - it's got a lot of potential - shadertoy with macros is super cool :-) 01:29 Baggers: so big thank you for making cepl :) 01:29 <Baggers> One thing though is the uniforms of the pipeline are the union of the uniforms in each gpu-func used as a stage. We can't pass just any uniforms to the pipeline as we need to be able to calculate a bunch of stuff ahead of time (uniforms locations etc). But allowing calling funcs with uniforms is feasible, I'd just need to test out what debugging the refactoring stuff is liek 01:29 <Baggers> krwq: cheers, its lovely seeing folks use it