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

111–120 of 162 posts

Re: Weep for Graphics Programming

#111

Post by fixermark »

corysama wrote: post #78
Athas wrote: post #53

Earlier quoted context omitted.

Couldn't a bytecode format have the same problem? Probably not with respect to parsing, but the semantics could still differ.

In theory, yes. Neither system represents perfection. But, what's more important in practice is the likelihood of problems. Parsing bytecode is trivial. Thus problems with drivers inconsistently rejecting D3D shader bytecode has been relatively rare. Parsing GLSL is quite hard. Thus, problems with drivers inconsistently rejecting GLSL text has been relatively common. OpenGL's text requirement makes great sense in the…

The software engineers who write drivers for graphics hardware have, unfortunately, an ill-earned reputation for being unable to code their way out of wet paper bags.

The fact that the GLSL standard forced every hardware vendor to vend a fully-functional compiler for a C-like language (even a simplified C-like language) is no small part of the source of that reputation.

Re: Weep for Graphics Programming

#113

Post by scott_s »

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…

I was poking around on your site, and I took a look at your publications list. I found this paper: http://futhark-lang.org/publications/icfp16.pdf

But it has no authors! I assume it was a double-blind submission to ICFP, which required removing the author names. When posting it publicly, though, I think you should put the author names back on. You don't want your work floating around the internet without your names attached.

Re: Weep for Graphics Programming

#114

Post by marssaxman »

fixermark wrote: post #101
viraptor wrote: post #27

Earlier quoted context omitted.

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

Yes, that is the problem: the compiler is embedded in the GPU driver. We can't do better because we can't build our own compilers.

Re: Weep for Graphics Programming

#115

Post by tyrust »

scrumper wrote: post #88

Slightly OT, but the literate presentation was nice. Any particular tool or technique you used for that? Thanks

From the Makefile [0] it looks like they are using Docco [1].

I agree that it's a very nice presentation of docs+code.

[0] - https://github.com/sampsyo/tinygl/blob/master/Makefile#L25

[1] - https://jashkenas.github.io/docco/

Re: Weep for Graphics Programming

#118

Post by Guvante »

yoklov wrote: post #29
tehrei wrote: post #20

Earlier quoted context omitted.

Vulkan and DirectX 12 are attempting to mitigate the driver problem by removing as much of the driver as possible. I've always sort of suspected AMD's Mantle initiative, which grew into the above two technologies, was at least partly motivated by their inability to ship a driver with the same performance as nVidia's...

Sadly, it looks very much like both Vulkan and DX12 are going the way of their predecessors. By which I mean tons of extensions, and nobody really thinks that they'll be able to avoid working around buggy games the same way previous drivers had to, do they? Maybe I'm being too cynical, but these seem like issues inherent in the situation, and not something caused by particular quirks in gl/dx.

> nobody really thinks that they'll be able to avoid working around buggy games the same way previous drivers had to, do they?

It depends, the running understanding was that when told to do X the driver actually did Y so the game did Z which the driver transformed to X. Unfortunately a latter update caused Z to become W so a game specific fix was added to make it "correctly" do X.

If Vulkan/DX12 can avoid the shell games then the whack-a-mole could in theory be eliminated.

> Maybe I'm being too cynical, but these seem like issues inherent in the situation, and not something caused by particular quirks in gl/dx.

It actually might be given the huge amount of underlying work the drivers were doing to maintain the fasade they were presenting. By removing much of the fasade it could help.

Re: Weep for Graphics Programming

#119

Post by kibwen »

mrec wrote: post #110
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-...

eholk was engaged with Rust as a part of an internship for his doctorate back in 2012, since then I guess he's just been occupied by other research.

Re: Weep for Graphics Programming

#120

Post by corysama »

fixermark wrote: post #111
corysama wrote: post #78

Earlier quoted context omitted.

In theory, yes. Neither system represents perfection. But, what's more important in practice is the likelihood of problems. Parsing bytecode is trivial. Thus problems with drivers inconsistently rejecting D3D shader bytecode has been relatively rare. Parsing GLSL is quite hard. Thus, problems with drivers inconsistently rejecting GLSL text has been relatively common. OpenGL's text requirement makes great sense in the…

The software engineers who write drivers for graphics hardware have, unfortunately, an ill-earned reputation for being unable to code their way out of wet paper bags. The fact that the GLSL standard forced every hardware vendor to vend a fully-functional compiler for a C-like language (even a simplified C-like language) is no small part of the source of that reputation.

You know what's great fun? Getting errors that only apply to desktop GLSL when trying to compile valid GLES GLSL. Can you guess how that particular vendor shortcutted implementing their ES compiler for that Android OS revision? Can you guess how likely it is that those Android customers will ever get a driver update? ;P
Post reply on HN