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

101–110 of 162 posts

Re: Weep for Graphics Programming

#101

Post by fixermark »

viraptor wrote: post #27
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…

I thought the problem is pretty much spelled out in that post: > [...] doesn’t solve the fundamental problem: the interface between the CPU and GPU code is needlessly dynamic, so you can’t reason statically about the whole, heterogeneous program. It's the same thing as raw SQL vs abstraction (could be ORM, but not necessarily). Not only are your assumptions not verified (is there table X, will I receive the columns I…

I think the author of the article may be failing to understand why the dynamism is there. It's, unfortunately, not needless.

The shader API is an API where the developer provides source code at runtime and then modifies inputs to the program compiled from the source code that runs on the user's GPU. It's a source-code level interface because it makes nearly zero assumptions about what capabilities the underlying hardware will have; interpretation and compilation of the source is left largely up to the vendor (literally, in the sense that the compiler is part of the GPU's driver kit and not part of the OpenGL library---an issue that has caused me HOURS of headache when encountering a bug in a closed-source graphics card's compiler, let me tell ya ;) ).

I strongly suspect a more compile-time-checkable API would lack the flexibility needed to capture all shader behavior---both when the API was codified and in the future. It's a pain in the ass to use, but I'm not convinced it's avoidable pain.

Re: Weep for Graphics Programming

#102

Post by angersock »

xigency wrote: post #85
datenwolf wrote: post #82

Earlier quoted context omitted.

> when this task used to be as simple as: a) Immediate Mode has been out of fashion for since before the turn of the century. Even the good old NVidia GeForce2 of 1998 already had OpenGL extensions that are essentially vertex buffer objects; you can in fact use the GL_ARB_vertex_buffer_object extension on a GeForce2. If you don't believe me, I'm currently headed to my mother's and I have a old box stored in her cella…

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.

Re: Weep for Graphics Programming

#103

Post by fixermark »

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…

Correct. What the author seems to be missing is that a different approach was already tried in the "fixed-function pipeline" era. Two issues were encountered:

1) Fixed-function utterly failed to capture the explosion of features as graphics card capability took off, having to fall back on nasty APIs like the OpenGL extensions system (where at a certain level of sophistication, more of your code is calling Glext functions than core OpenGL functions---when everything is an extension, nothing is)

2) Compile-time-checkable behavior was accomplished via function calls, but it turned out that making a lot of function calls created significantly non-trivial runtime overhead, and performance is king in graphics. It's hard to get good static checking on a model of "Rip a bunch of bits into a binary buffer and then ship that whole buffer to the GPU," but that model is a lot faster than many-function-call-based alternatives.

Re: Weep for Graphics Programming

#104

Post by DonHopkins »

DreemGL [1] [2] addresses these problems by compiling JavaScript code into shaders.

"DreemGL is an open-source multi-screen prototyping framework for mediated environments, with a visual editor and shader styling for webGL and DALi runtimes written in JavaScript." [3]

[1] https://github.com/dreemproject/dreemgl

[2] http://docs.dreemproject.org/docs/api/index.html#!/guide/dre...

[3] https://dreemproject.org/

Re: Weep for Graphics Programming

#105

Post by DonHopkins »

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…

I learned a lot about how WebGL works by studying the "twgl" library, which is basically a thin wrapper around WebGL that automates all the boilerplate stuff. It's true to the WebGL way of doing things, and doesn't add much beyond that.

"This library's sole purpose is to make using the WebGL API less verbose."

https://twgljs.org/

Re: Weep for Graphics Programming

#106

Post by overgard »

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…

> 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.

I can confirm this happens a LOT. (At least with ESSL) In it's defense, it usually is a mistake I made, but some implementations are definitely more lenient than others.

Re: Weep for Graphics Programming

#107

Post by fixermark »

xigency wrote: post #54
datenwolf wrote: post #34

Earlier quoted context omitted.

> When writing my first OpenGL code, I was stunned by the amount of boilerplate required. Huh, actually the amount of boilerplate required for getting a triangle to the screen with OpenGL is minimal. - Create a context - fill a buffer with the triangle vertex data - load buffer to OpenGL - create vertex shader implementing vertex to position transformation - create vertex shader implementing pixel coloirization - iss…

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 operation, stack teardown.... Per function call. You're more-or-less tripling the cost of describing your vertices.

We can ignore that cost on desktop machines (well, we COULD, if people didn't want to play the latest and greatest games in CRYENGINE or what have you ;) ). The cost was not ignorable in time-constrained, power-constrained architectures.

Simpler to reason about, but flatly the wrong solution for performant graphics on a coprocessor.

Re: Weep for Graphics Programming

#108

Post by tlarkworthy »

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…

My aha moment came by reading Unity's 'built in shaders', which are faily simple. I found tutorials for shaders are for rendering things far more complex than a simple sprite.

You can download just the Unity shaders via the download dropdown: https://unity3d.com/get-unity/download/archive

Those shaders give you (battle tested) base cases for really common functionality.

Re: Weep for Graphics Programming

#109

Post by fixermark »

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…

Your advice is sound, if maddening (it's maddening to have to debug a black box; I've hit bugs in shader compilers before that had me tearing my hair out. Things should not be fixable by multiplying a quantity by 1.0 in a sane world ;) ).

Re: Weep for Graphics Programming

#110

Post by mrec »

kvark wrote: post #42

In Rust ecosystem, we've been experimenting with different ways to make CPU-GPU interaction safer when it comes to graphics abstractions. In gfx-rs [1] one defines a Pipeline State Object with a macro, and then all the input/output data and resources are just fields in a regular Rust struct [2]. So assignment pretty much works as one expects. All the compatibility checks are done at run (init) time, when the shader p…

Is eholk no longer active in Rust-land? I remember reading his post [1] about compiling Rust for GPUs (i.e. app code + OpenCL kernels from a single source) back in 2012 and getting quite excited. Presumably generating SPIR-V wouldn't be vastly different in principle.

[1] http://blog.theincredibleholk.org/blog/2012/12/05/compiling-...

Post reply on HN