Could somebody help me understand what exactly this is? The description tells about 2D rendering, and it seems that it sits on top of, for example, Vulkan, so my best guess it is a 2D rendering library to be used in games or other applications (as opposed to, say, a compositor, hardware driver, OpengL implementation, Vulkan implementation, or whatever else it could be).
Background: This actually seems related to a pet project of mine, tinkering with graphics rendering on an FPGA. An application-side 2D renderer would be very interesting to me to better understand the application side of it, when building the hardware side. Especially when it is a renderer that uses a presumably modern approach of using shaders for everything, making the hardware side insanely flexible, and because there are already plenty of other renderers to understand a static rendering pipeline.
I think you are still assuming some context to understand your comment that I'm still missing. By "directly using gpu" you probably mean without Vulkan and without any operating-system-level graphics driver, right? I.e. writing to GPU registers directly.
Does this project assume any other operating system level infrastructure? If so, which OS -- Linux, Windows, BSD, ...?
When modern GPU graphics are used, it's assumed that an API layer is also used. This allows the drivers to implement the API specification within approximations appropriate to the hardware. The OS, drivers and API all collaborate to provide a consistent abstraction similar to a file system or sockets; a header file is included to use the API, and the initialization process creates a GPU context, which allows binding of resources etc. There are some examples of direct register programming, but nearly all come from gaming consoles with fixed hardware and tight performance budgets.
Vulkan is simply the lowest-level approach currently available among the major APIs. Piet is an example of a rendering engine that stands on top of Vulkan: it still needs application code to be a complete renderer, but it provides higher level abstractions that speak in the desired domain language(shapes, vector data, etc.).
Pretty much all of the rendering pipeline runs on the GPU, in compute shaders. In most 2D renderers, the CPU is doing a lot of the work (tesselating vector shapes into triangle meshes, computing bounding boxes, etc). In piet-gpu, the CPU just encodes a high-level, declarative description of the scene (semantically similar to SVG) in an efficient binary format, and the GPU does the rest.
Regarding hardware support, it needs a GPU capable of compute shaders (which rules out a bunch of the older or very low end mobile chips). There is a hardware abstraction layer which currently supports Vulkan, Direct3D12, and Metal, but I believe D3D11 could be added, as well as other lower level interfaces (I took a look at deko3d and was tempted to use that as a way to port to Nintendo Switch).
A Intel GPU might be behind Vulkan, WebGL2, DX12, D3D11, WebGPU, OpenGL4, GLES3.2,or Metal ... There are a similar nr of current GPU hw architectures as current GPU APIs, is there still a portability benefit from the API abstractions or are they just zero or negative sum competition?
I think this is designed to be a 2d rendering library (similar to skia or cairo) which forms the basis on which an application GUI toolkit could be built. I'm pretty sure it's designed to work cross-platform (although I'm not sure if the current prototype does), although it probably relies on an OS of some sort being available.
Piet is the backend for the Druid UI toolkit. It is indeed cross-platform. The SVG backend looks like it would work without an OS, but I'm not sure the value of a GUI toolkit without an OS anyway :)
A GPU toolkit without an OS API could be useful for WASM rendering, and a rendering library without a GUI is useful for headless rendering (matplotlib graphing, video generation/compositing, meme generators, etc.).
Background: This actually seems related to a pet project of mine, tinkering with graphics rendering on an FPGA. An application-side 2D renderer would be very interesting to me to better understand the application side of it, when building the hardware side. Especially when it is a renderer that uses a presumably modern approach of using shaders for everything, making the hardware side insanely flexible, and because there are already plenty of other renderers to understand a static rendering pipeline.