it's vector graphics on gpu. traditionally vector graphics is done on cpu and cached on a texture.

this project seeks to draw vector graphics directly using gpu.

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.).

directly using gpu == using vulkan shader

this paper explains it well

https://w3.impa.br/~diego/projects/GanEtAl14/

Or the OP's earlier blog post

https://raphlinus.github.io/rust/graphics/gpu/2019/05/08/mod...

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 :)

https://github.com/linebender/piet#backends

https://github.com/linebender/druid/tree/master/druid-shell/...

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.).