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

41–50 of 162 posts

Re: Weep for Graphics Programming

#41

Post by chiph »

fauigerzigerk wrote: post #38
rwmj wrote: post #35

Earlier quoted context omitted.

10 years ago I wrote a thing called PG'OCaml which integrates OCaml and SQL in a type safe way. You write code like: PGSQL(dbh) "insert into employees (name, salary, email) values ($name, $salary, $?email)" and it (at compile time) creates the correct PREPARE+EXECUTE pair and checks types across the languages. (It's not obvious but it is also free of SQL injections.) For example if your OCaml 'salary' variable was a…

This used to be how a lot of SQL code was written. I think it's about as old as SQL itself. See Oracle's Pro*C for instance. It's a C precompiler that generates API calls and optionally does type checking. There's even an ANSI/ISO standard for embedded SQL.

Yep. I used to use the Sybase SQL precompiler in OS/2 with Watcom C++. Nullable columns were a pain because you had to define a separate boolean variable to hold the null status for each one.

Re: Weep for Graphics Programming

#42

Post by kvark »

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 programs are linked/reflected.

In vulkano [3] the Rust structures are generated at compile time by analyzing your SPIR-V code.

  [1] https://github.com/gfx-rs/gfx
  [2] https://github.com/gfx-rs/gfx/blob/2c00b52568e5e7da3df227d415eab9f55feba5a9/examples/shadow/main.rs#L314
  [3] https://github.com/tomaka/vulkano

Re: Weep for Graphics Programming

#43

Post by sillysaurus3 »

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.

This doesn't have anything to do with shaders as strings. It's been true since the beginning of shader programming, whether bytecode shaders or otherwise.

Re: Weep for Graphics Programming

#44

Post by DanielRibeiro »

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…

GPipe also provides a typesafe api to OpenGL, but in Haskell

[1] http://tobbebex.blogspot.se/

Re: Weep for Graphics Programming

#45

Post by ufo »

sillysaurus3 wrote: post #43
corysama wrote: post #37

Earlier quoted context omitted.

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. This doesn't have anything to do with shaders as strings. It's been true since the beginning of shader programmi…

His point is that shaders-as-strings have a larger surface area for misinterpretation than shaders-as-bytecode.

Re: Weep for Graphics Programming

#46

Post by rwmj »

datenwolf wrote: post #34
kirillkh wrote: 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…

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

I think you missed:

- spend a few hours working out why your display window just shows black

Re: Weep for Graphics Programming

#47

Post by ufo »

k__ wrote: post #21
haxiomic wrote: post #13

The haxe-language project 'hxsl' takes a pretty good stab at improving the situation. With hxsl you write your GPU and CPU code in the same language (haxe) and it generates shader strings (in GLSL or AGAL) at compiletime along with CPU code for whatever platform you're targeting. There's not a lot of documentation around it at the moment but the author explains a little about it in this video https://youtu.be/-WeGME_…

Isn't this kinda normal with all the query-builders for DBs? Why isn't it used more excessively with shaders? Because they're Turing-complete?

I doubt it. SQL (with enough extensions) can also be Turing complete (or pretty close to it).

Re: Weep for Graphics Programming

#48

Post by marmaduke »

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…

Furthark looks really nice, but what does the future look like for it?

(I'm currently working on a Python hpc codebase with pyopencl and would be interested in reducing some of the manual labor required for cpu-gpu coordination)

Re: Weep for Graphics Programming

#49

Post by vvanders »

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…

I've also been really impressed with glium. I don't think I've ever had as nice of a blank editor -> quad on the screen experience in a long while. At least since the days of fixed-function.

I say this as someone who's written ~2 commercial renderers from some various degrees from scratch. Normally it's 1-2 days to just setup all the various infra for handling shaders/uniforms/etc.

Re: Weep for Graphics Programming

#50

Post by heavenlyhash »

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 keep looking for a better way".

A quick, frank throwdown of "this is the way it is" like this would've gotten me over that hump much faster. Even if it's crushing, I'm filing this link away for "must read" when someone asks me where to get started in GL programming.

Post reply on HN