Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Frickin' shaders with frickin' laser beams

acko.net

Post reply on HN
Print view View original

21–27 of 27 posts

Re: Frickin' shaders with frickin' laser beams

#21

Post by gugagore »

aappleby wrote: post #10

"In my case, I want to construct and call any shader I want at run-time. Arbitrary composition is the entire point. This implies that when I want to go make a GPU call, I need to generate and link a new program, based on the specific types and access patterns of values being passed in." For toy apps, sure. For professional apps or games, abso-frickin-lutely not. Shader compilation jank is still an annoying issue in e…

So what does one do in professional apps? Make sure all the shaders are compiled ahead of time? How does that help?

Re: Frickin' shaders with frickin' laser beams

#22

Post by djmips »

vanderZwan wrote: post #7

> The key thing is that I don't intend to make thousands of draw calls this way either. I just want to make a couple dozen of exactly the draw calls I need, preferably today, not next week. It's a radically different use case from what game engines need, which is what the current industry APIs are really mostly tailored for. Whenever I try to learn WebGL (or similar technology) I give up after a while. In my head I i…

Why not learn Unity then?

Re: Frickin' shaders with frickin' laser beams

#23

Post by inDigiNeous »

Enjoyed looking at the code, might want to try this system out when WebGPU starts to be more relevant. The importing of .glsl symbols somehow into typescript would be perfect for playing around with effects.

Many times it would be better to have a simple way to express ideas, not having to deal with the most performant systems, which might take a lot more figuring out or issues with debugging your shaders.

Re: Frickin' shaders with frickin' laser beams

#25

Post by greggman3 »

aappleby wrote: post #10

"In my case, I want to construct and call any shader I want at run-time. Arbitrary composition is the entire point. This implies that when I want to go make a GPU call, I need to generate and link a new program, based on the specific types and access patterns of values being passed in." For toy apps, sure. For professional apps or games, abso-frickin-lutely not. Shader compilation jank is still an annoying issue in e…

Seems like you'd just compute combinations at compile time. The point of the article is not that things should be done at runtime, the point of the article is that the entire system can be made easier to use by putting more smarts in front. Those smarts can happen at runtime or compile time.

Re: Frickin' shaders with frickin' laser beams

#26

Post by davedx »

Can't believe this doesn't have more upvotes, seems like it could be a pretty groundbreaking project to advance the state of the art of GPU programming.

Having done a decent amount of games development, and a little bit of shader coding, the pain points fixed by the approach in the article are significant. Really impressive stuff.

I didn't even realize it was going to be TypeScript until much later in the article too, that was the cherry on top :)

Re: Frickin' shaders with frickin' laser beams

#27

Post by vanderZwan »

djmips wrote: post #22
vanderZwan wrote: post #7

> The key thing is that I don't intend to make thousands of draw calls this way either. I just want to make a couple dozen of exactly the draw calls I need, preferably today, not next week. It's a radically different use case from what game engines need, which is what the current industry APIs are really mostly tailored for. Whenever I try to learn WebGL (or similar technology) I give up after a while. In my head I i…

Why not learn Unity then?

Because I'm not interested in making games. Recommending Unity is like saying "well if F1 is too high-tech for you try NASCAR" - it sort of helps but it's honestly missing the point.
Post reply on HN