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

Weep for Graphics Programming

adriansampson.net

Post reply on HN
Print view View original

91–100 of 162 posts

Re: Weep for Graphics Programming

#91

Post by sillypog »

xigency wrote: post #58

It seems unlikely that any of this will change, because control is in the hands of a relatively few powerful organizations who honestly have no interest in making life easier for software engineers working on graphics programming; and those engineers who do have to put up with it have long since given up or chalk it up to experience; and those developers would probably resist any changes now simply because change req…

With Apple releasing Metal, I think the vendors do have an interest in making developers lives easier if it helps to draw them into their platform. I'm just glad OpenGL is still supported at this point.

Re: Weep for Graphics Programming

#92

Post by zeveb »

junke wrote: post #6

Young fool, only now, at the end, do you understand... code is data. CEPL demos: https://www.youtube.com/watch?v=2Z4GfOUWEuA&list=PL2VAYZE_4w... I get it, there are many good reasons to stick to C++ if you want to ship a game today.

> Young fool, only now, at the end, do you understand... code is data.

And clearly storing C in strings is a saner way to handle code than as Lisp stored in S-expressions. Who could possibly doubt it?

Re: Weep for Graphics Programming

#94

Post by marssaxman »

ixtli wrote: post #55

Very well written. I get the sense that the reason we're all here now is that historically the people who use these APIs as client programmers have been somewhat bad at explaining what they want.

Rather: it's because the companies building the hardware have jealously guarded their machine languages, treating their drivers as a source of competitive advantage. We'd have fixed the problems ourselves years ago if we could, but GPU manufacturers like to keep it all locked up tight and secret, so we can't.

Re: Weep for Graphics Programming

#95

Post by Impossible »

pjc50 wrote: post #76
heavenlyhash wrote: post #50

Upvoted simply because -- notwithstanding all of the entirely valid complaints -- this is actually the short, sweet introduction to GL that I would've loved when I first picked it up. All of these things took me some serious time to learn. Partly because of my sheer incredulity at the stringliness of it all. Finding good GL tutorials is hard, after all: "surely", I thought, "these are just bad examples, and I should…

There are surprisingly many systems where the tutorials have to start with "First, paste this thousand lines of boilerplate startup code. Then you can add 'hello, world' at the bottom." FPGA programming is another example.

I consistently read complaints about boilerplate code in low level graphics APIs, but I'm never clear about what people want from a low boilerplate graphics API. I'm strongly against low level graphics APIs sacrificing performance or control in order to appeal to beginners or casual users, but from the comments on Hackernews it seems like there is a need for something more accessible. Elsewhere in this thread someone said that drawing a quad should be a one liner, this assumes a ton of opinionated default state, and what makes sense might vary based on your use case and the power of your hardware (2D quads for UI? 3D quads to draw a heightfield? light or unlit? what BRDF? shadows? etc.)

To me this low boilerplate API implies something closer to Processing, Openframeworks, THREE.js or Cinder, but I rarely see those recommended as options in OpenGL threads like this. Is this a marketing problem? Is it because programmers are taught that real programmers use mostly raw OpenGL if they want to take advantage of the graphics pipeline? Is it because HN users are curious and this is a learning exercise? I'm asking because I'd like to look into writing a library, framework or set of tutorials that appeals to programmers that are interested in graphics programming, find modern OpenGL too verbose or intimidating and whose needs are not met by an existing library, framework or game engine. This might end up being an educational resource that helps people unfamiliar with graphics or game technology understand their options based on their use case. I imagine that many of the people that think they need to learn OpenGL would be completely happy with Unity3D, for example.

Re: Weep for Graphics Programming

#96

Post by eropple »

chongli wrote: post #81
eropple wrote: post #64

Earlier quoted context omitted.

That sounds great. Are you going to pay for it? That isn't an attempt at snark--RISC-V is interesting. It isn't competitive . GPU technology is very interesting. This, without dump trucks of cash, won't be competitive, either. There is a question of cui bono here, and you need to answer that to make what you advocate make sense.

dump trucks of cash How about $30,000[0]? Seriously, it's not the 90s anymore. The cost of making a chip is not insane and it's going to go down every year. As Moore's Law slows to a halt, we enter the golden age of computer architecture[1]. [0] http://www.eetimes.com/author.asp?doc_id=1327291 [1] https://www.youtube.com/watch?v=mD-njD2QKN0

The cost of making a chip anybody wants to use is not $30,000, though. nVidia gets my money because their GPU technology is good enough to, at a reasonable price point, do absolutely anything I'm likely to encounter in the next 3-5 years. You're fighting against significant economies of scale as well as a significant technical deficit.

Don't get me wrong: it would be awesome if this existed. But I think that, like RISC-V, it's predicated on a heavy hitter getting something significant out of doing it. I'm not sure who will do that without the ROI in play.

Re: Weep for Graphics Programming

#97

Post by junke »

zeveb wrote: post #92
junke wrote: post #6

Young fool, only now, at the end, do you understand... code is data. CEPL demos: https://www.youtube.com/watch?v=2Z4GfOUWEuA&list=PL2VAYZE_4w... I get it, there are many good reasons to stick to C++ if you want to ship a game today.

> Young fool, only now, at the end, do you understand... code is data. And clearly storing C in strings is a saner way to handle code than as Lisp stored in S-expressions. Who could possibly doubt it?

Who doesn't like having to escape double-quotes and newlines or the simple yet powerful aesthetics of programs entirely styled in font-lock-string-face?

Re: Weep for Graphics Programming

#98

Post by fixermark »

pjc50 wrote: post #28
IvanK_net wrote: post #23

I did not find anything interesting or useful in this article. Author just says, that OpenGL and "shaders as strings" are bad, without explaining why. Then author speaks about some mysterious "Heterogeneity" without specifying what it means. "We need programming models that let us write one program that spans multiple execution contexts" - what does it mean? How should that model look like, how should it be different…

Communication between the part of the program that runs on the CPU and the part that runs on the GPU is typeless and requires manually marshalling arguments. Javascript programmers will shrug at this, but for people used to strong type checking and better automarshalling of RPC it's very disappointing.

As a fun exercise, try sketching out what a stronger-typed API for shaders and shader parameters would look like.

It's a useful exercise in understanding why such a thing wasn't done.

Re: Weep for Graphics Programming

#99

Post by angersock »

Impossible wrote: post #95
pjc50 wrote: post #76

Earlier quoted context omitted.

There are surprisingly many systems where the tutorials have to start with "First, paste this thousand lines of boilerplate startup code. Then you can add 'hello, world' at the bottom." FPGA programming is another example.

I consistently read complaints about boilerplate code in low level graphics APIs, but I'm never clear about what people want from a low boilerplate graphics API. I'm strongly against low level graphics APIs sacrificing performance or control in order to appeal to beginners or casual users, but from the comments on Hackernews it seems like there is a need for something more accessible. Elsewhere in this thread someone…

"I imagine that many of the people that think they need to learn OpenGL would be completely happy with Unity3D, for example."

This isn't quite my experience. Unity3D can put a lot of bullshit between you and a simple update loop for testing out an idea spike.

Many times, you really just want a "poll events/update state/draw shit" loop, bereft of anything else.

OpenGL 1.x and GLUT were actually pretty much perfect for this use case--the fixed-function pipeline made splatting up things really easy to understand. As hardware moved away from that model, and as people kept wanting to bolt on more features, life got too complicated, and the only solution was to say "Okay, screw it, you all write the shaders you want".

Your point about "what makes sense" is a good one--people don't seem to grasp that in order to have the functionality they might want in a graphics API at the performance they think they need, they need to have a toolset that lets them build large pipelines.

When you're building what is in nature a big refinery, you shouldn't complain about boilerplate. At that scale, it's not.

Re: Weep for Graphics Programming

#100

Post by chongli »

eropple wrote: post #96
chongli wrote: post #81

Earlier quoted context omitted.

dump trucks of cash How about $30,000[0]? Seriously, it's not the 90s anymore. The cost of making a chip is not insane and it's going to go down every year. As Moore's Law slows to a halt, we enter the golden age of computer architecture[1]. [0] http://www.eetimes.com/author.asp?doc_id=1327291 [1] https://www.youtube.com/watch?v=mD-njD2QKN0

The cost of making a chip anybody wants to use is not $30,000, though. nVidia gets my money because their GPU technology is good enough to, at a reasonable price point, do absolutely anything I'm likely to encounter in the next 3-5 years. You're fighting against significant economies of scale as well as a significant technical deficit. Don't get me wrong: it would be awesome if this existed. But I think that, like RI…

I agree that you're not soon likely to replace your shiny $400 Nvidia graphics card with something designed by a bunch of students and faculty at Berkeley. However, what about your phone? If you watch Prof Patterson's talk, you'll be astounded at what they've been able to do with modern tools and a small team of students. Now think of some larger, slightly-more funded teams such as LowRISC[0] and you begin to see the possibilities. Raspberry Pi proved there is demand for this sort of thing.

[0] http://www.lowrisc.org/

Post reply on HN