Support OpenGL / non-gfx backends

[dhardy]

Via WebGPU, KAS already supports DX11 / DX12 / Vulkan / Metal APIs. It appears that wgpu aims to support GL / other backends directly, so maybe we can just wait for that.

There are some alternatives, e.g. Piet supports Direct2D and Cairo backends. In turn, Cairo supports multiple targets (with hardware acceleration in some cases). Building a KAS toolkit over Cairo or Piet (or maybe even Druid) would be feasible, though significant extra work.

[skyne98]

Hey there, what do you think about Euc? It seems to provide pretty reasonable and easy to use software rendering capabilities in pure rust.

[dhardy]

Looks good enough to be worth a try (via new kas_euc lib), though it won't be high on my priority list. Questions:

• Is there a compatibility layer for winit (via raw-window-handle)? KAS is designed to support other windowing libs (such as minifb), but in practice this would be a significant amount of extra work (because of the very different input API). (One would think that this is easy, but somehow there don't appear to be any non-accelerated raw-window-handle graphics kits yet, nor is it obvious from the API.)
• How much of themes & draw pipe implementations should be shared across kas-* backends? This is a question for further down the road, but it's worth noting that themes with complex lighting models make less sense without GPU-acceleration, and that draw APIs are far from fixed yet. As a short-term goal, copying (and if necessary simplifying) existing code makes the most sense.
• This may increase motivation for supporting partial redraws ("damage" events); this is already partially supported within KAS.

[skyne98]

To be honest, I am pretty sure that this crate doesn't support raw-window-handles and does windowing directly, internally. Also, I am not even sure it's capable of headless rendering that can be later copied onto a different window texture.

I agree that without GPU acceleration it won't really make sense to implement fancy graphics for the UIs. However, I think that it should optional as I believe most modern CPUs are fully capable of rendering very complex graphics with proper optimizations (look at this, as an example). Maybe it should be implemented in a way of having a SimpleTheme fallback, that will be used by a CPU renderer whenever it's actually available? So, something like { theme: Theme, low_theme: Option<Theme> }. It will also be nice to have a possibility to enable it manually for some users with very old hardware (maybe one day WebGPU will be implemented using OpenGL).

Partial events sound very awesome, to be honest, but I have no expertise in them, unfortunately.

[dhardy]

Also, I am not even sure it's capable of headless rendering that can be later copied onto a different window texture.

It operates on a simple 2D buffer, that much is clear. Also, the examples use minifb for windowing (which supports direct writing to a buffer).

Probably it would be possible to create a cross-platform crate (for common targets) providing a writeable 2D buffer from a raw window handle, but it doesn't appear to exist yet.

[skyne98]

So, as far as I can understand, it would be nice to have a library built on top of something like winit which gives access to a buffer of pixel data directly?

[dhardy]

Progress: wgpu now has improved opengl support, allowing many examples to run on opengl. Currently this requires using the wgpu/cross feature (see README), but will not be the case with the next wgpu release. Either way the Mandlebrot example is problematic since it uses f64 shaders; possibly we will have to change that.

[Aloso]

@dhardy I got it working on a machine running Linux that doesn't support Vulkan. It only works if the KAS_BACKENDS=GL environment variable is set; otherwise I get this error:

[2021-08-03T13:58:22Z ERROR gfx_backend_vulkan] 
    GENERAL [Loader Message (0x0)] : setupLoaderTermPhysDevs:  Failed to detect any valid GPUs in the current config
    object info: (type: INSTANCE, hndl: 0x55d45d347d30)
    
[2021-08-03T13:58:22Z ERROR gfx_backend_vulkan] 
    GENERAL [Loader Message (0x0)] : setupLoaderTrampPhysDevs:  Failed during dispatch call of 'vkEnumeratePhysicalDevices' to lower layers or loader to get count.
    object info: (type: INSTANCE, hndl: 0x55d45d347d30)
    
[2021-08-03T13:58:22Z ERROR gfx_backend_vulkan] Could not enumerate physical devices! Initialization of a object has failed
Error: NoAdapter

Although it works with the environment variable set, the following is printed to the terminal:

[2021-08-03T13:59:08Z ERROR wgpu_core::validation] Unexpected varying type: Array { base: [1], size: Constant([5]), stride: 4 }
[2021-08-03T13:59:08Z ERROR wgpu_core::validation] Unexpected varying type: Array { base: [1], size: Constant([5]), stride: 4 }
[2021-08-03T13:59:08Z ERROR wgpu_core::validation] Unexpected varying type: Array { base: [1], size: Constant([5]), stride: 4 }
[2021-08-03T13:59:08Z ERROR wgpu_core::validation] Unexpected varying type: Array { base: [1], size: Constant([5]), stride: 4 }
[2021-08-03T13:59:08Z ERROR wgpu_core::validation] Unexpected varying type: Array { base: [1], size: Constant([5]), stride: 4 }
[2021-08-03T13:59:08Z ERROR wgpu_core::validation] Unexpected varying type: Array { base: [1], size: Constant([5]), stride: 4 }
[2021-08-03T13:59:08Z ERROR wgpu_core::validation] Unexpected varying type: Array { base: [4], size: Constant([6]), stride: 4 }
[2021-08-03T13:59:08Z ERROR wgpu_core::validation] Unexpected varying type: Array { base: [4], size: Constant([6]), stride: 4 }
[2021-08-03T13:59:08Z ERROR wgpu_core::validation] Unexpected varying type: Array { base: [4], size: Constant([6]), stride: 4 }
[2021-08-03T13:59:08Z ERROR wgpu_core::validation] Unexpected varying type: Array { base: [4], size: Constant([6]), stride: 4 }

[dhardy]

@Aloso I get similar errors when running with Vulkan; I haven't really investigated since they don't appear to be a problem. See gfx-rs/wgpu#1427

[dhardy]

Since updating to WGPU v0.10.0 (#241), the OpenGL backend seems to "just work", aside from 64-bit shaders. If there are other problems please open a new issue.

I'm going to drop plans for a pure CPU backend, though it is possible, given sufficient demand.