Nannou: Investigate the possibility of switching to Vulkan

Created on 9 Apr 2018  路  4Comments  路  Source: nannou-org/nannou

Requirements

  • We must be able to support cross-platform compilation without requiring the user download any third-party libs, etc. This includes building and running on macOS and ultimately would include supporting ARM based processors like raspberry pi etc. It looks like some companies have been recently having some luck with apple-based platforms here.
  • Must allow for freely creating commercial works without any platform-specific license caveats or 3rd-party non-free frameworks (don't know if this discludes Molten on macos anymore?).
  • It must be easy enough to write the backend. If the process of integrating vulkano is at least almost as easy as it currently is to setup GL using glium then we should be OK. However, if we have to write our own entire graphics pipeline from scratch on top of very low-level vulkan support we probably would not have the time and would be better off sticking with OpenGL until something higher-level appears. Will have to investigate what kind of high-level APIs vulkan requires.
  • Must work on stable rust.
  • Must continue to work with a simple cargo run.
  • Must actually simplify

Nice-to-haves

  • We should be able to support existing GLSL code. It may not be worth switching from OpenGL if it means abandoning all the awesome shader code out there that already exists. However, if instead we could use some kind of rust-style shading language instead (like RLSL) to which glsl shaders could be ported then maybe it would be worth it.

After having a quick look at vulkano it looks like it might already be close to ticking all these boxes today! We would want to test that the simple triangle example compiles and runs easily on each of the major platforms first (macos, windows, linux). If not, we will have to investigate how easy it is to automate the downloading/installation of any necessary 3rd party free tools etc via a build.rs script.

graphics

Most helpful comment

This interesting thread popped up in /r/rust recently.

My current thoughts are that, I value the "correctness" goals of vulkano enough to put up with some incomplete-ness and breakage in the short-term if it means we don't have to write our own unsafe API around some lower level crate like vk-sys. I would much prefer to have the rust compiler and type-system inform me of what "is" and "isn't" allowed in Vulkan's API than use some other more "flexible" crate that requires I comb over the vulkan documentation to ensure I'm using it correctly and don't run into weird vulkan-specific / GPU bugs. Having used glium, I know that tomaka is capable of pulling off very nice, type-safe APIs over renownly terrible, complex libraries (see OpenGL), however it doesn't look like he's been active on vulkano over the last month so it would be worth enquiring about the future of the crate before adding it as a dependency.

All 4 comments

Required Steps

Currently glium is used throughout nannou to provide support for OpenGL. The following are the steps required to make the switch to Vulkano.

  • Switching from using the glutin window and glcontext to vulkano-win.
  • Removing GlFrame from the frame module for the vulkano alternative.
  • Changing the nannou::draw::backend module to use vulkano.
  • Switch from using the glium backend of conrod to a vulkano one.

This interesting thread popped up in /r/rust recently.

My current thoughts are that, I value the "correctness" goals of vulkano enough to put up with some incomplete-ness and breakage in the short-term if it means we don't have to write our own unsafe API around some lower level crate like vk-sys. I would much prefer to have the rust compiler and type-system inform me of what "is" and "isn't" allowed in Vulkan's API than use some other more "flexible" crate that requires I comb over the vulkan documentation to ensure I'm using it correctly and don't run into weird vulkan-specific / GPU bugs. Having used glium, I know that tomaka is capable of pulling off very nice, type-safe APIs over renownly terrible, complex libraries (see OpenGL), however it doesn't look like he's been active on vulkano over the last month so it would be worth enquiring about the future of the crate before adding it as a dependency.

Yeh I agree, perhaps we could also contribute to vulkano to fix and incomplete-ness / breakage

Closed via #216.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

kvark picture kvark  路  3Comments

sulram picture sulram  路  6Comments

mkesper picture mkesper  路  4Comments

tpltnt picture tpltnt  路  4Comments

batchku picture batchku  路  3Comments