2020-05-13 03:53:54 +10:00
|
|
|
use piet_gpu_derive::piet_gpu;
|
|
|
|
|
|
|
|
piet_gpu! {
|
|
|
|
#[gpu_write]
|
|
|
|
mod annotated {
|
2021-03-19 05:21:07 +11:00
|
|
|
struct AnnoImage {
|
implement FillImage command and sRGB support
FillImage is like Fill, except that it takes its color from one or
more image atlases.
kernel4 uses a single image for non-Vulkan hosts, and the dynamic sized array
of image descriptors on Vulkan.
A previous version of this commit used textures. I think images are a better
choice for piet-gpu, for several reasons:
- Texture sampling, in particular textureGrad, is slow on lower spec devices
such as Google Pixel. Texture sampling is particularly slow and difficult to
implement for CPU fallbacks.
- Texture sampling need more parameters, in particular the full u,v
transformation matrix, leading to a large increase in the command size. Since
all commands use the same size, that memory penalty is paid by all scenes, not
just scenes with textures.
- It is unlikely that piet-gpu will support every kind of fill for every
client, because each kind must be added to kernel4.
With FillImage, a client will prepare the image(s) in separate shader stages,
sampling and applying transformations and special effects as needed. Textures
that align with the output pixel grid can be used directly, without
pre-processing.
Note that the pre-processing step can run concurrently with the piet-gpu pipeline;
Only the last stage, kernel4, needs the images.
Pre-processing most likely uses fixed function vertex/fragment programs,
which on some GPUs may run in parallel with piet-gpu's compute programs.
While here, fix a few validation errors:
- Explicitly enable EXT_descriptor_indexing, KHR_maintenance3,
KHR_get_physical_device_properties2.
- Specify a vkDescriptorSetVariableDescriptorCountAllocateInfo for
vkAllocateDescriptorSets. Otherwise, variable image2D arrays won't work (but
sampler2D arrays do, at least on my setup).
Updates #38
Signed-off-by: Elias Naur <mail@eliasnaur.com>
2020-12-29 08:02:39 +11:00
|
|
|
bbox: [f32; 4],
|
2021-03-19 05:21:07 +11:00
|
|
|
linewidth: f32,
|
implement FillImage command and sRGB support
FillImage is like Fill, except that it takes its color from one or
more image atlases.
kernel4 uses a single image for non-Vulkan hosts, and the dynamic sized array
of image descriptors on Vulkan.
A previous version of this commit used textures. I think images are a better
choice for piet-gpu, for several reasons:
- Texture sampling, in particular textureGrad, is slow on lower spec devices
such as Google Pixel. Texture sampling is particularly slow and difficult to
implement for CPU fallbacks.
- Texture sampling need more parameters, in particular the full u,v
transformation matrix, leading to a large increase in the command size. Since
all commands use the same size, that memory penalty is paid by all scenes, not
just scenes with textures.
- It is unlikely that piet-gpu will support every kind of fill for every
client, because each kind must be added to kernel4.
With FillImage, a client will prepare the image(s) in separate shader stages,
sampling and applying transformations and special effects as needed. Textures
that align with the output pixel grid can be used directly, without
pre-processing.
Note that the pre-processing step can run concurrently with the piet-gpu pipeline;
Only the last stage, kernel4, needs the images.
Pre-processing most likely uses fixed function vertex/fragment programs,
which on some GPUs may run in parallel with piet-gpu's compute programs.
While here, fix a few validation errors:
- Explicitly enable EXT_descriptor_indexing, KHR_maintenance3,
KHR_get_physical_device_properties2.
- Specify a vkDescriptorSetVariableDescriptorCountAllocateInfo for
vkAllocateDescriptorSets. Otherwise, variable image2D arrays won't work (but
sampler2D arrays do, at least on my setup).
Updates #38
Signed-off-by: Elias Naur <mail@eliasnaur.com>
2020-12-29 08:02:39 +11:00
|
|
|
index: u32,
|
|
|
|
offset: [i16; 2],
|
|
|
|
}
|
2021-03-17 22:02:41 +11:00
|
|
|
struct AnnoColor {
|
2020-05-13 03:53:54 +10:00
|
|
|
bbox: [f32; 4],
|
2021-03-17 22:02:41 +11:00
|
|
|
// For stroked fills.
|
2020-05-13 03:53:54 +10:00
|
|
|
// For the nonuniform scale case, this needs to be a 2x2 matrix.
|
|
|
|
// That's expected to be uncommon, so we could special-case it.
|
|
|
|
linewidth: f32,
|
2021-03-19 05:21:07 +11:00
|
|
|
rgba_color: u32,
|
|
|
|
}
|
2021-06-24 04:50:51 +10:00
|
|
|
struct AnnoLinGradient {
|
|
|
|
bbox: [f32; 4],
|
|
|
|
// For stroked fills.
|
|
|
|
linewidth: f32,
|
|
|
|
index: u32,
|
|
|
|
line_x: f32,
|
|
|
|
line_y: f32,
|
|
|
|
line_c: f32,
|
|
|
|
}
|
2021-03-19 05:21:07 +11:00
|
|
|
struct AnnoBeginClip {
|
|
|
|
bbox: [f32; 4],
|
|
|
|
linewidth: f32,
|
2020-05-13 03:53:54 +10:00
|
|
|
}
|
2021-03-19 05:21:07 +11:00
|
|
|
struct AnnoEndClip {
|
2020-11-20 06:53:59 +11:00
|
|
|
bbox: [f32; 4],
|
|
|
|
}
|
2020-05-13 03:53:54 +10:00
|
|
|
enum Annotated {
|
|
|
|
Nop,
|
2021-03-17 22:02:41 +11:00
|
|
|
Color(TagFlags, AnnoColor),
|
2021-06-24 04:50:51 +10:00
|
|
|
LinGradient(TagFlags, AnnoLinGradient),
|
2021-03-19 05:21:07 +11:00
|
|
|
Image(TagFlags, AnnoImage),
|
|
|
|
BeginClip(TagFlags, AnnoBeginClip),
|
|
|
|
EndClip(AnnoEndClip),
|
2020-05-13 03:53:54 +10:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|