Live data from Hacker News

Weep for Graphics Programming

adriansampson.net

141–150 of 162 posts

Re: Weep for Graphics Programming

#141
post #17

I spent a lot of time making toy engines with XNA and carried much of its lessons to my toy engines in C++. If your asset can be built, then your asset should be built. Content pipelines. > Shaders are Strings If you're using Vulkan, compile your shaders to SPIR-V alongside your project. If you're using OpenGL you're mostly out of luck - but there's still no reason to inline the shaders even with the most rudimentary…

The Vulkan comment is particularly relevant, and the reason that technology exists is because of OpenGL's quirks.

This whole article is whinging against things that people have known for a while and have been working to fix. Sometimes it's not easy.

Re: Weep for Graphics Programming

#142
Source code or IR or whatever else would always be needed, I'm afraid, with a late (and, likely, unpredictable) compilation. Passing an image of a different format may trigger a dynamic shader (or OpenCL kernel) recompilation on some GPUs, for example.

Re: Weep for Graphics Programming

#143
post #128

Earlier quoted context omitted.

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, framebuff…

> Vulkan honestly doesn't look much better.

What? Vulkan seems to give pretty good access to hardware command buffers etc. It's pretty good API for low overhead graphics.

> I've only dipped my toes into Metal, but it looks like it has solved some of these issues.

I looked into it, and couldn't even find proper C bindings. Isn't it also only available on some OS X and iOS devices?

Re: Weep for Graphics Programming

#144
post #76

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.

FPGA programming? Surely not. If you've got a nicely supported dev board then it's simply a case of loading up a board support package, selecting some pins, and your first program can be three lines long. I will admit the toolchain can be a pain to set up but that's an entirely different problem.

Re: Weep for Graphics Programming

#145
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…

The boilerplate is boilerplate because there are a few exceptional cases in scope where you might do something slightly differently. Since you can't completely abstract it out, it becomes boilerplate of some form. Either you're using boilerplate to set up a configuration object to feed into an initializer, or you're using initialization boilerplate.

It turns out that with graphics APIs, you actually have to layer many, many abstractions on top before you get into useful territory, which is why I'd say that 99% of use cases are better off using a high level library/engine even if all you want to do is draw a few things.

I've written my own graphics engines on top of OpenGL, and in my experience the set of people "whose needs are not met by an existing library, framework or game engine" is actually much slimmer than that set of people might think. Sure, Unity or Unreal or even Ogre3D might be overkill and might not give you all of the nuances you need, but they actually make some excellent abstractions that are well worth the tradeoffs and workarounds.

In most cases, if you need to do "custom stuff" that a "mid level" engine like Ogre3D offers, either your project is so sophisticated that it's worth redoing boilerplate, or you're asking for more than you really need, or you just want the fun of building your own engine, because it's really a lot of fun. What Unity and Unreal add on top of that are even more abstractions and tools for an entire production pipeline of artists, modelers, and programmers. But they do a great job of covering the vast majority of use cases. It's like if you told me that your application asks for things jQuery can't do... I'd question what kind of situation you're in that jQuery does things incompatibly.

This post though, about shaders, has a point regardless of OpenGL boilerplate. Shaders suck everywhere, even in engines. You're probably writing your own shaders that do 90% of what most shaders do and 10% of specifically what you needed, and you're probably trying to work through all of the complexities of "uniform" variables and how other bits and pieces of the rendering pipeline fit together. That part always sucks regardless of OpenGL, D3D, Unity, Unreal, etc.

Re: Weep for Graphics Programming

#147

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…

If anyone is looking for a more in-depth 'OpenGL For Dummies' tutorial, I wholeheartedly recommend Anton's OpenGL Tutorials^. It's written in a similar style to this blog post - plain English with simple minimal examples to follow along with - but it also goes into the math behind a lot of common rendering techniques.

It's really good, and I wish that I'd known about it years ago.

^ http://antongerdelan.net/opengl/

Re: Weep for Graphics Programming

#148
post #8

When writing my first OpenGL code, I was stunned by the amount of boilerplate required. It is so bad it reminds me of COBOL. No one in their right mind would tolerate that monstrosity in a normal CPU program (except, possibly, some hardcore C++ fans). I think in order to solve this, we need three things: 1) Intermediate representation for compiled GPU code. Bytecode mentioned in the article sounds like it. 2) Cross-p…

The core problem is library infrastructure and tooling of our programming language.

> Compiler plugins and DSLs

Name me a non-lisp language that supports that. A lot of LLVM based languages are making progress in that direction (by providing an ability to hook into the LLVM IR at least). But this problem is all programming languages, graphics is just a pain point because of it.

Re: Weep for Graphics Programming

#149
post #96

Earlier quoted context omitted.

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…

> Raspberry Pi proved there is demand for this sort of thing.

RPi proved nothing of the sort. You are still relying on a commercial vendor to provide the VLSI chips. And, I assure you, they didn't make that chip for the RPi.

Open chips for phones? I couldn't stop laughing. Phones are all about minimizing power consumption. That requires that you be on nearly the newest fab technology.

If OpenRISC/LowRISC/RISC were serious, they've got a really good market to jam themselves into--Bluetooth Low Energy and WiFi chips. The margins on those chips have gotten so small that everybody is doing anything to avoid having to pay ARM money.

So, why aren't those chip vendors adopting the "open" stuff instead of hand-rolling their own?

Re: Weep for Graphics Programming

#150
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…

Something like Three.JS has some serious weaknesses: one of which is the obsessive object orientation, which makes it essentially impossible to share a program and VBO between draws. More objects -> even worse overhead.

Honestly, I think that it's necessary to expose people to something like OpenGL, because it at least somewhat communicates the real costs of operations. I don't think it's exactly a marketing problem so much as a practicality problem. If you want to ship something which Three.JS can render with decent performance, it's a good tradeoff. If your abstraction prevents you from implementing what you want, it's an unacceptable tradeoff.

Post reply on HN