Hacker News new | past | comments | ask | show | jobs | submit login

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



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.


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 solid: http://tomaka.github.io/glium/book/tuto-01-getting-started.h...

Next time I'm starting up a GL project it's going to be hard for me to argue C/C++ given how nice some of the semantics around Rust's OpenGL libraries are.


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


If you want to use a higher-level framework then one-liner might make sense.

For OpenGL you want control over state changes, uniforms and a slew of other things. Otherwise your performance/control will suffer significantly.

Look at the things I listed there, that's the bare minimum you need to do the above, and fitting that in one page is pretty impressive.


OpenGL is set up to optimize for all those things, instead of optimizing for the learner/simple case.

It's definitely a valid approach, but it means for simple cases, you're copy & pasting a lot of boilerplate for performance, control, and a slew of other things you don't need.

You have to learn/paste a lot before you get a little reward.


There is also kiss3d for some higher-level rendering:

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


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

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


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: