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

121–130 of 162 posts

Re: Weep for Graphics Programming

#121

Post by vvanders »

datenwolf wrote: post #69
rwmj wrote: post #46

Earlier quoted context omitted.

I think you missed: - spend a few hours working out why your display window just shows black

> - spend a few hours working out why your display window just shows black I hardly ever had this kind of problem… and I'm doing OpenGL programming for almost two decades now. Yes, when implementing a new shader (idea) I often am greeted with a blank window, too. This is where the "stringiness" of OpenGL is actually a huge benefit . See, you don't have to recompile your program just to change things in the shader. In…

There's nothing intrinsic to graphics work there, you're just talking about content-driven development which is common in a bunch of domains.

Your not hitting the black-screen since you've been doing it self-admitted for 20 years. Kudos, good for you.

The problem is getting fresh-blood in who have a hunger to learn but don't have a deep understanding of shaders, pipelines, vertices, etc. It's really easy to make a trivial mistake in that boiler plate(I've seen someone fight something for hours until they thought to turn of culling, they just had their winding wrong).

Case in point from one of the foremost figures in the domain:

https://twitter.com/id_aa_carmack/status/370205518532329472

PIX was about the most sane step in the direction of fixing this, sadly tools seem to have slid backwards of late.

Re: Weep for Graphics Programming

#122

Post by ordinary »

jdonaldson wrote: post #80
ordinary wrote: post #19

Earlier quoted context omitted.

Sounds like hxsl doesn't actually solve most of the problems described in the article, but just obscures them in a layer of indirection. If you're generating shader strings at compile-time, you still have to compile them at runtime, for instance, just like before, and the GPU/CPU gap is only marginally reduced. It might solve some other problems with GPU programming, though?

I wouldn't call it obscuring, you can see exactly what is getting passed to the card just the same as if you had written it manually. The key is that you're dealing with the shader language by using a language, rather than strings. You can use static type information. You can refactor more easily. You can create abstractions over the minor variations in card behaviors more easily. While hxsl doesn't directly address…

Yeah, you're right. I shouldn't have used that word.

Re: Weep for Graphics Programming

#123

Post by xigency »

angersock wrote: post #102
xigency wrote: post #85

Earlier quoted context omitted.

Yes, I'm aware of how both immediate mode and vertex arrays work in OpenGL. The problem, and this is even getting away from what the article addresses, is that a green developer approaching the application must learn an entirely new language (shaders) before drawing a single primitive. In mattbee's example, what is the beginner supposed to think of the line "#version 410" or "in vec3 vp" which is not even C code? I'm…

The beginner needs to rise to the task. GLSL isn't complex at all , least of all because its problem domain is basically pure math. It should take less than an afternoon to understand how to write a shader if they have any familiarity with math. If they don't know math, they shouldn't be doing shader programming until they learn .

Writing a fixed function shader is to learning graphics programming what writing a Makefile is to learning C++. I'm not saying it's not important, or not important in the long run, but what introductory programming book would start out showing how to use a linker instead of how to write a program? In this case things are compounded by the fact that there is no linker, which means the programmer has to shuffle around string programs at runtime.

I agree, though, that shader writing should help with learning 3D math. Saying GLSL is not complex is a bit of an overstatement, though. The language is simple, but the fact is that GLSL doesn't behave like C with certain statements, and not knowing everything will make things complicated.

You've also described a chicken-and-egg problem. Can't make a 3D app till you learn GLSL, can't use GLSL until you make a 3D app.

It also feels absurd to be writing any static language code wrapped in a string, in JavaScript, to be sent to a GPU and then compiled. The user doesn't have newlines, let alone syntax highlighting. Sure, most WebGL developers will just use Three.js but then they aren't really learning anything, anyway, and we still have these patchwork solutions.

Re: Weep for Graphics Programming

#124

Post by Impossible »

angersock wrote: post #99
Impossible wrote: post #95

Earlier quoted context omitted.

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…

I agree that Unity3D is overkill for many use cases, although its not many steps to get something that looks roughly like a fixed function OpenGL 1.x and GLUT application working for quick, code only prototypes, so I'm curious what you think is a lot of bullshit. I find that Processing has less boilerplate and more functionality than oldschool OpenGL + GLUT but it gets dismissed by a lot of people because its seen as more of a learning or non-coder environment, even if it's usually sufficient for many quick graphics prototypes.

This is why I asked if its more of a marketing\perception problem, or maybe a workflow problem, than a real problem.

Maybe the answer is to build a portable environment that completely emulates fixed function OpenGL from the 90s and can build all the NeHe tutorials, although that sounds really regressive to me.

Re: Weep for Graphics Programming

#125

Post by kvark »

continuational wrote: post #86
vvanders wrote: post #65

Earlier quoted context omitted.

To expand on this a tad, here's the intro code for glium, getting a triangle on the screen is just one page of text: https://github.com/tomaka/glium/blob/master/examples/tutoria... That includes: Window creation and event handling, fragment shader, vertex shader, varying declaration and binding. Uniforms are pretty trivial on top of this(also done via macros so there's no raw strings). The whole tutorial is really so…

But still, just one page of code? Ideally, drawing a quad should be a one-liner.

There is also kiss3d for some higher-level rendering:

https://github.com/sebcrozet/kiss3d/blob/master/examples/cub...

Re: Weep for Graphics Programming

#126

Post by xigency »

fixermark wrote: post #107
xigency wrote: post #54

Earlier quoted context omitted.

And yet you've just described a decent amount of boilerplate. The fact that future iterations of OpenGL and OpenGL ES have nuked the fixed function pipeline is sort of annoying. I'm not saying there should be more codepaths in the implementation, but if there were a default compiled fixed function vertex shader and fragment shader, it would be helpful. What you've just described for rendering one primitive includes c…

Fundamentally, the biggest problem with the fixed-function model and the vertex-plotting calls in the "red book" is they don't scale. They just don't. :( There's a reason OpenGL ES threw most of that baby and bathwater out---it's not to diminish the footprint of the library on storage (even in an embedded device, memory's cheap for long-term storage). It's that those function calls are each a stack setup, library ope…

My argument is not to keep the interfaces and functionality of the OLD pipeline, but to maintain a reasonable, fixed-function shader that is a default out-of-the-box. The most general purpose fragment/vertex shader for drawing a triangle and maybe texturing it is 120 lines top, which actually compiled in the driver would be a couple of hundred bytes. The real cost of not including that feature, or including it in the software library, is preventing new developers from easily experimenting with 3D programming in the browser and on portable devices, which is a fairly large loss of creativity in an emerging area.

Re: Weep for Graphics Programming

#127

Post by xigency »

robbies wrote: post #90

I think the author has good intentions (don't we all), but I don't think he understands enough about graphics programming to make some of the proclamations/requests in the article. Not that I blame him...it's hard to get an understanding of GPU programming outside the scope of a game dev or IHV. > To define an object’s appearance in a 3D scene, real-time graphics applications use shaders... Eh, the shaders are just a…

"Eh, I don't think I want a common programming model across CPUs and GPUs. They are fundamentally different machines, and I don't think it makes sense to try to lump them together."

Well, except for APU's, which I think is an unstated target for this discussion. Or on-board graphics chips.

In these cases, there is almost certainly extra work being done, regardless of your programming philosophy.

Re: Weep for Graphics Programming

#128

Post by vitd »

Impossible wrote: post #124
angersock wrote: post #99

Earlier quoted context omitted.

"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…

I agree that Unity3D is overkill for many use cases, although its not many steps to get something that looks roughly like a fixed function OpenGL 1.x and GLUT application working for quick, code only prototypes, so I'm curious what you think is a lot of bullshit. I find that Processing has less boilerplate and more functionality than oldschool OpenGL + GLUT but it gets dismissed by a lot of people because its seen as…

Here are things that made learning OpenGL extremely painful for me:

- I came from doing graphics on the CPU where you were often handed a buffer of ARGB pixels and did whatever the heck you wanted to them. You could call OS or library routines to draw simple 2D shapes, text, or images, or you could write directly to the buffer if you were generating a pattern or writing a ray tracer. Understanding textures, framebuffers, 3D polygons etc. was really strange. (What do you mean I have to draw geometry if I just want to display a JPEG? WTF?)

- Understanding the state machine and having to hook up so much crap for simple operations. I can't tell you how many times I wrote, or even copied existing working code into a program, and it resulted in nothing on the screen, and no errors. It was almost always because I either hadn't enabled some state or hadn't bound some thing to some particular location. And there's no way to debug that other than stumbling around and asking vague questions online because you don't have any idea what's going on, unless you're already an expert and know what to look for.

- The complete lack of modern language features in the API, such as using enums instead of #defines. This means you can do stuff like call glBegin(GL_LINE) and if you don't check glGetError() (another stupid pattern!) you'll never realize it's supposed to be glBegin(GL_LINES), but you just won't see anything rendered.

- Having 20 different versions of each function for every combination of data type and size. (e.g. glColor3b, glColor3f, glColor4f, glColor4i, etc., etc.)

The entire API is horrible. I'm sure it's all related to how SGI machines worked in the early 90s and how graphics hardware evolved since then, but it made the whole thing shitty to work with. We have a solution now, which is to use one of the new APIs. Vulkan honestly doesn't look much better. I've only dipped my toes into Metal, but it looks like it has solved some of these issues.

I almost wonder if libraries that are more specialized would be useful? Unity seems as hard to learn as OpenGL (and if you want to understand why things are going wrong, you probably have to understand OpenGL anyway). Something specific to image processing might be easier to understand for people doing that, for example. I'm sure there are other niches that would benefit from libraries that hide the complexity of OpenGL (or whichever library you build it on top of).

Re: Weep for Graphics Programming

#129

Post by leetNightshade »

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.

Even with C++, a modern flexible C++ game engine should be mostly data driven. For flexibility and being able to have faster iteration times, changing data at run-time and seeing results almost instantly is necessary, with the level of quality people demand from games these days.

Granted that's not the case across the board, but people have been pushing for data driven C++ game engines for years.

Re: Weep for Graphics Programming

#130

Post by p0nce »

corysama wrote: post #37
Athas wrote: post #33

I'm not sure why bytecode is supposed to be significantly better than storing the shaders as strings. Sure, you get rid of a complex parser and can more easily use it as a compiler target, but the core problem remains: the compiler can still not reason across the device boundary. The CPU compiler does not understand what happens on the GPU, and the GPU compiler has no idea what the CPU is going to do do it. Although…

The issue is that every driver implementation ever ships with a slightly different implementation of that complex parser. That means (every mobile device)X(every OS update) and (every PC ad-in card)X(every driver update) all have the potential to misinterpret/reject your shaders in slightly different ways. Case in point: I recently learned that "#line 0" is a spec violation. A single OS revision of a single Android d…

Can empathize with that. The problem with OpenGL is not really the API but the impossibility to really have something correct. There is a sheer difficulty of finding combinations of GPU x drivers x OS to test OpenGL. It's quite common that the drivers lie or reject something valid.
Post reply on HN