Go to file
Raph Levien 2c0f1d3cdd
Merge pull request #25 from ztlpn/fix-mapping-size
Fix read mapping size in the Vulkan adapter
2020-07-02 11:45:50 -07:00
piet-gpu Shader documentation and a slight cleanup 2020-06-28 15:37:27 +02:00
piet-gpu-derive Merge branch 'master' into master 2020-04-21 15:18:51 -07:00
piet-gpu-hal Fix read mapping size (size is number of bytes, not number of items) 2020-07-02 21:32:17 +03:00
piet-gpu-types Start GPU-side flattening 2020-06-09 16:01:47 -07:00
.gitignore Starting piet-gpu repo 2020-04-05 15:17:26 -07:00
Cargo.lock Minor cleanups 2020-06-10 14:10:28 -07:00
Cargo.toml Update to piet 0.13 2020-05-12 08:26:48 -07:00
LICENSE-APACHE Licenses and README 2020-04-15 08:56:39 -07:00
LICENSE-MIT Licenses and README 2020-04-15 08:56:39 -07:00
README.md Minor fix on paragraph 35 2020-06-15 11:15:32 -03:00

piet-gpu

This repo contains the new prototype for a new compute-centric 2D GPU renderer.

It succeeds the previous prototype, piet-metal.

Goals

The main goal is to answer research questions about the future of 2D rendering:

  • Is a compute-centered approach better than rasterization (Direct2D)? How much so?

  • To what extent do "advanced" GPU features (subgroups, descriptor arrays) help?

Another goal is to explore a standards-based, portable approach to GPU compute.

Non-goals

There are a great number of concerns that need to be addressed in production:

  • Compatibility with older graphics hardware (including runtime detection)

  • Asynchrony

  • Swapchains and presentation

Notes

A more detailed explanation will come. But for now, a few notes.

Why not gfx-hal?

It makes a lot of sense to use gfx-hal, as it addresses the ability to write kernel and runtime code once and run it portably. But in exploring it I've found some points of friction, especially in using more "advanced" features. To serve the research goals, I'm enjoying using Vulkan directly, through ash, which I've found does a good job tracking Vulkan releases. One example is experimenting with VK_EXT_subgroup_size_control.

The hal layer in this repo is strongly inspired by gfx-hal, but with some differences. One is that we're shooting for a compile-time pipeline to generate GPU IR on DX12 and Metal, while gfx-hal ships SPIRV-Cross in the runtime. To access Shader Model 6, that would also require bundling DXC at runtime, which is not yet implemented (though it's certainly possible).

Why not wgpu?

The case for wgpu is also strong, but it's even less mature. I'd love to see it become a solid foundation, at which point I'd use it as the main integration with druid.

In short, the goal is to facilitate the research now, collect the data, and then use that to choose a best path for shipping later.