alex/vello
1
0
Fork 0
mirror of https://github.com/italicsjenga/vello.git synced 2024-10-18 07:21:30 +11:00
Code Issues Packages Projects Releases Wiki Activity
vello/piet-gpu/shader/kernel4.comp

302 lines
12 KiB
GLSL
Raw Normal View History

all: add SPDX license headers Fixes #53 Signed-off-by: Elias Naur <mail@eliasnaur.com>
2020-12-12 01:01:48 +11:00
// SPDX-License-Identifier: Apache-2.0 OR MIT OR Unlicense
Add draft kernel 4 Render from ptcl rather than original scene.
2020-04-22 12:30:14 +10:00
// This is "kernel 4" in a 4-kernel pipeline. It renders the commands
// in the per-tile command list to an image.
// Right now, this kernel stores the image in a buffer, but a better
// plan is to use a texture. This is because of limited support.
#version 450
#extension GL_GOOGLE_include_directive : enable
More blend mode fixes Adds a test to visualize the blend modes. Fixes a dumb bug in blend.h and also a more subtle issue where default blending is not the same as clipping, as the former needs to always push a blend group (to cause isolation) and the latter does not. This might be something we need to get back to. This should fix the rendering, so it fairly closely resembles the Mozilla reference image. There's also a compile-time switch to disable sRGB conversion, which is (sadly) needed for compatible rendering.
2022-05-18 07:34:14 +10:00
// We can do rendering either in sRGB colorspace (for compatibility)
// or in a linear colorspace, with conversions to sRGB (which will give
// higher quality antialiasing among other things).
#define DO_SRGB_CONVERSION 0
Implement robust dynamic memory This is the core logic for robust dynamic memory. There are changes to both shaders and the driver logic. On the shader side, failure information is more useful and fine grained. In particular, it now reports which stage failed and how much memory would have been required to make that stage succeed. On the driver side, there is a new RenderDriver abstraction which owns command buffers (and associated query pools) and runs the logic to retry and reallocate buffers when necessary. There's also a fairly significant rework of the logic to produce the config block, as that overlaps the robust memory. The RenderDriver abstraction may not stay. It was done this way to minimize code disruption, but arguably it should just be combined with Renderer. Another change: the GLSL length() method on a buffer requires additional infrastructure (at least on Metal, where it needs a binding of its own), so we now pass that in as a field in the config. This also moves blend memory to its own buffer. This worked out well because coarse rasterization can simply report the size of the blend buffer and it can be reallocated without needing to rerun the pipeline. In the previous state, blend allocations and ptcl writes were interleaved in coarse rasterization, so a failure of the former would require rerunning coarse. This should fix #83 (finally!) There are a few loose ends. The binaries haven't (yet) been updated (I've been testing using a hand-written test program). Gradients weren't touched so still have a fixed size allocation. And the logic to calculate the new buffer size on allocation failure could be smarter. Closes #175
2022-06-24 01:48:26 +10:00
// TODO: the binding of the main buffer can be readonly
unify GPU memory management Merge all static and dynamic buffers to just one, "memory". Add a malloc function for dynamic allocations. Unify static allocation offsets into a "config" buffer containing scene setup (number of paths, number of path segments), as well as the memory offsets of the static allocations. Finally, set an overflow flag when an allocation fail, and make sure to exit shader execution as soon as that triggers. Add checks before beginning execution in case the client wants to run two or more shaders before checking the flag. The "state" buffer is left alone because it needs zero'ing and because it is accessed with the "volatile" keyword. Fixes #40 Signed-off-by: Elias Naur <mail@eliasnaur.com>
2020-12-12 04:30:20 +11:00
#include "mem.h"
all: add optional memory checks Defining MEM_DEBUG in mem.h will add a size field to Alloc and enable bounds and alignment checks for every memory read and write. Notes: - Deriving an Alloc from Path.tiles is unsound, but it's more trouble to convert Path.tiles from TileRef to a variable sized Alloc. - elements.comp note that "We should be able to use an array of structs but the NV shader compiler doesn't seem to like it". If that's still relevant, does the shared arrays of Allocs work? Signed-off-by: Elias Naur <mail@eliasnaur.com>
2020-12-24 22:00:53 +11:00
#include "setup.h"
Update winit example
2020-06-15 07:32:59 +10:00
Create chunks over the x axis in addition to y axis This allows more coalescing with image loads/stores, since all of our images are stored with a tiled layout.
2021-03-23 22:54:49 +11:00
#define CHUNK_X 2
#define CHUNK_Y 4
shaders: Add .clang-format and reformat Helps keeping the code tidy. Style is chosen to minimize diff, but contains a slight bit of personal taste.
2022-01-30 18:23:18 +11:00
#define CHUNK (CHUNK_X * CHUNK_Y)
Create chunks over the x axis in addition to y axis This allows more coalescing with image loads/stores, since all of our images are stored with a tiled layout.
2021-03-23 22:54:49 +11:00
#define CHUNK_DX (TILE_WIDTH_PX / CHUNK_X)
#define CHUNK_DY (TILE_HEIGHT_PX / CHUNK_Y)
layout(local_size_x = CHUNK_DX, local_size_y = CHUNK_DY) in;
Add draft kernel 4 Render from ptcl rather than original scene.
2020-04-22 12:30:14 +10:00
Implement robust dynamic memory This is the core logic for robust dynamic memory. There are changes to both shaders and the driver logic. On the shader side, failure information is more useful and fine grained. In particular, it now reports which stage failed and how much memory would have been required to make that stage succeed. On the driver side, there is a new RenderDriver abstraction which owns command buffers (and associated query pools) and runs the logic to retry and reallocate buffers when necessary. There's also a fairly significant rework of the logic to produce the config block, as that overlaps the robust memory. The RenderDriver abstraction may not stay. It was done this way to minimize code disruption, but arguably it should just be combined with Renderer. Another change: the GLSL length() method on a buffer requires additional infrastructure (at least on Metal, where it needs a binding of its own), so we now pass that in as a field in the config. This also moves blend memory to its own buffer. This worked out well because coarse rasterization can simply report the size of the blend buffer and it can be reallocated without needing to rerun the pipeline. In the previous state, blend allocations and ptcl writes were interleaved in coarse rasterization, so a failure of the former would require rerunning coarse. This should fix #83 (finally!) There are a few loose ends. The binaries haven't (yet) been updated (I've been testing using a hand-written test program). Gradients weren't touched so still have a fixed size allocation. And the logic to calculate the new buffer size on allocation failure could be smarter. Closes #175
2022-06-24 01:48:26 +10:00
layout(binding = 1) restrict readonly buffer ConfigBuf {
unify GPU memory management Merge all static and dynamic buffers to just one, "memory". Add a malloc function for dynamic allocations. Unify static allocation offsets into a "config" buffer containing scene setup (number of paths, number of path segments), as well as the memory offsets of the static allocations. Finally, set an overflow flag when an allocation fail, and make sure to exit shader execution as soon as that triggers. Add checks before beginning execution in case the client wants to run two or more shaders before checking the flag. The "state" buffer is left alone because it needs zero'ing and because it is accessed with the "volatile" keyword. Fixes #40 Signed-off-by: Elias Naur <mail@eliasnaur.com>
2020-12-12 04:30:20 +11:00
Config conf;
Add draft kernel 4 Render from ptcl rather than original scene.
2020-04-22 12:30:14 +10:00
};
Implement robust dynamic memory This is the core logic for robust dynamic memory. There are changes to both shaders and the driver logic. On the shader side, failure information is more useful and fine grained. In particular, it now reports which stage failed and how much memory would have been required to make that stage succeed. On the driver side, there is a new RenderDriver abstraction which owns command buffers (and associated query pools) and runs the logic to retry and reallocate buffers when necessary. There's also a fairly significant rework of the logic to produce the config block, as that overlaps the robust memory. The RenderDriver abstraction may not stay. It was done this way to minimize code disruption, but arguably it should just be combined with Renderer. Another change: the GLSL length() method on a buffer requires additional infrastructure (at least on Metal, where it needs a binding of its own), so we now pass that in as a field in the config. This also moves blend memory to its own buffer. This worked out well because coarse rasterization can simply report the size of the blend buffer and it can be reallocated without needing to rerun the pipeline. In the previous state, blend allocations and ptcl writes were interleaved in coarse rasterization, so a failure of the former would require rerunning coarse. This should fix #83 (finally!) There are a few loose ends. The binaries haven't (yet) been updated (I've been testing using a hand-written test program). Gradients weren't touched so still have a fixed size allocation. And the logic to calculate the new buffer size on allocation failure could be smarter. Closes #175
2022-06-24 01:48:26 +10:00
layout(binding = 2) buffer BlendBuf {
uint blend_mem[];
};
Mostly working rendering This exposes interfaces to render glyphs into a texture atlas. The main changes are: * Methods to plumb raw Metal GPU resources (device, texture, etc) into piet-gpu-hal objects. * A new glyph_render API specialized to rendering glyphs. This is basically the same as just painting to a canvas, but will allow better caching (and has more direct access to fonts, bypassing the Piet font type which is underdeveloped). * Ability to render to A8 target in addition to RGBA. WIP, there are some rough edges, not least of which is that the image format changes are only on mac and cause compile errors elsewhere.
2022-01-20 06:58:01 +11:00
#ifdef GRAY
Implement robust dynamic memory This is the core logic for robust dynamic memory. There are changes to both shaders and the driver logic. On the shader side, failure information is more useful and fine grained. In particular, it now reports which stage failed and how much memory would have been required to make that stage succeed. On the driver side, there is a new RenderDriver abstraction which owns command buffers (and associated query pools) and runs the logic to retry and reallocate buffers when necessary. There's also a fairly significant rework of the logic to produce the config block, as that overlaps the robust memory. The RenderDriver abstraction may not stay. It was done this way to minimize code disruption, but arguably it should just be combined with Renderer. Another change: the GLSL length() method on a buffer requires additional infrastructure (at least on Metal, where it needs a binding of its own), so we now pass that in as a field in the config. This also moves blend memory to its own buffer. This worked out well because coarse rasterization can simply report the size of the blend buffer and it can be reallocated without needing to rerun the pipeline. In the previous state, blend allocations and ptcl writes were interleaved in coarse rasterization, so a failure of the former would require rerunning coarse. This should fix #83 (finally!) There are a few loose ends. The binaries haven't (yet) been updated (I've been testing using a hand-written test program). Gradients weren't touched so still have a fixed size allocation. And the logic to calculate the new buffer size on allocation failure could be smarter. Closes #175
2022-06-24 01:48:26 +10:00
layout(r8, binding = 3) uniform restrict writeonly image2D image;
Mostly working rendering This exposes interfaces to render glyphs into a texture atlas. The main changes are: * Methods to plumb raw Metal GPU resources (device, texture, etc) into piet-gpu-hal objects. * A new glyph_render API specialized to rendering glyphs. This is basically the same as just painting to a canvas, but will allow better caching (and has more direct access to fonts, bypassing the Piet font type which is underdeveloped). * Ability to render to A8 target in addition to RGBA. WIP, there are some rough edges, not least of which is that the image format changes are only on mac and cause compile errors elsewhere.
2022-01-20 06:58:01 +11:00
#else
Implement robust dynamic memory This is the core logic for robust dynamic memory. There are changes to both shaders and the driver logic. On the shader side, failure information is more useful and fine grained. In particular, it now reports which stage failed and how much memory would have been required to make that stage succeed. On the driver side, there is a new RenderDriver abstraction which owns command buffers (and associated query pools) and runs the logic to retry and reallocate buffers when necessary. There's also a fairly significant rework of the logic to produce the config block, as that overlaps the robust memory. The RenderDriver abstraction may not stay. It was done this way to minimize code disruption, but arguably it should just be combined with Renderer. Another change: the GLSL length() method on a buffer requires additional infrastructure (at least on Metal, where it needs a binding of its own), so we now pass that in as a field in the config. This also moves blend memory to its own buffer. This worked out well because coarse rasterization can simply report the size of the blend buffer and it can be reallocated without needing to rerun the pipeline. In the previous state, blend allocations and ptcl writes were interleaved in coarse rasterization, so a failure of the former would require rerunning coarse. This should fix #83 (finally!) There are a few loose ends. The binaries haven't (yet) been updated (I've been testing using a hand-written test program). Gradients weren't touched so still have a fixed size allocation. And the logic to calculate the new buffer size on allocation failure could be smarter. Closes #175
2022-06-24 01:48:26 +10:00
layout(rgba8, binding = 3) uniform restrict writeonly image2D image;
Mostly working rendering This exposes interfaces to render glyphs into a texture atlas. The main changes are: * Methods to plumb raw Metal GPU resources (device, texture, etc) into piet-gpu-hal objects. * A new glyph_render API specialized to rendering glyphs. This is basically the same as just painting to a canvas, but will allow better caching (and has more direct access to fonts, bypassing the Piet font type which is underdeveloped). * Ability to render to A8 target in addition to RGBA. WIP, there are some rough edges, not least of which is that the image format changes are only on mac and cause compile errors elsewhere.
2022-01-20 06:58:01 +11:00
#endif
Add draft kernel 4 Render from ptcl rather than original scene.
2020-04-22 12:30:14 +10:00
Implement robust dynamic memory This is the core logic for robust dynamic memory. There are changes to both shaders and the driver logic. On the shader side, failure information is more useful and fine grained. In particular, it now reports which stage failed and how much memory would have been required to make that stage succeed. On the driver side, there is a new RenderDriver abstraction which owns command buffers (and associated query pools) and runs the logic to retry and reallocate buffers when necessary. There's also a fairly significant rework of the logic to produce the config block, as that overlaps the robust memory. The RenderDriver abstraction may not stay. It was done this way to minimize code disruption, but arguably it should just be combined with Renderer. Another change: the GLSL length() method on a buffer requires additional infrastructure (at least on Metal, where it needs a binding of its own), so we now pass that in as a field in the config. This also moves blend memory to its own buffer. This worked out well because coarse rasterization can simply report the size of the blend buffer and it can be reallocated without needing to rerun the pipeline. In the previous state, blend allocations and ptcl writes were interleaved in coarse rasterization, so a failure of the former would require rerunning coarse. This should fix #83 (finally!) There are a few loose ends. The binaries haven't (yet) been updated (I've been testing using a hand-written test program). Gradients weren't touched so still have a fixed size allocation. And the logic to calculate the new buffer size on allocation failure could be smarter. Closes #175
2022-06-24 01:48:26 +10:00
layout(rgba8, binding = 4) uniform restrict readonly image2D image_atlas;
Start work on gradients WIP. Most of the GPU-side work should be done (though it's not tested end-to-end and it's certainly possible I missed something), but still needs work on encoding side.
2021-06-24 04:50:51 +10:00
Implement robust dynamic memory This is the core logic for robust dynamic memory. There are changes to both shaders and the driver logic. On the shader side, failure information is more useful and fine grained. In particular, it now reports which stage failed and how much memory would have been required to make that stage succeed. On the driver side, there is a new RenderDriver abstraction which owns command buffers (and associated query pools) and runs the logic to retry and reallocate buffers when necessary. There's also a fairly significant rework of the logic to produce the config block, as that overlaps the robust memory. The RenderDriver abstraction may not stay. It was done this way to minimize code disruption, but arguably it should just be combined with Renderer. Another change: the GLSL length() method on a buffer requires additional infrastructure (at least on Metal, where it needs a binding of its own), so we now pass that in as a field in the config. This also moves blend memory to its own buffer. This worked out well because coarse rasterization can simply report the size of the blend buffer and it can be reallocated without needing to rerun the pipeline. In the previous state, blend allocations and ptcl writes were interleaved in coarse rasterization, so a failure of the former would require rerunning coarse. This should fix #83 (finally!) There are a few loose ends. The binaries haven't (yet) been updated (I've been testing using a hand-written test program). Gradients weren't touched so still have a fixed size allocation. And the logic to calculate the new buffer size on allocation failure could be smarter. Closes #175
2022-06-24 01:48:26 +10:00
layout(rgba8, binding = 5) uniform restrict readonly image2D gradients;
Towards wiring up images to k4 This patch passes a dynamically sized array of textures to the fine rasterizer. A bunch of the low level Vulkan stuff is done, but only enough of the shaders and encoders to do minimal testing. We'll want to switch from storage images to sampled images, track the actual array of textures during encoding, use that to build the descriptor set (which will need to be more dynamic), and of course run image elements through the pipeline. Progress towards #38
2020-11-19 10:54:11 +11:00
Add draft kernel 4 Render from ptcl rather than original scene.
2020-04-22 12:30:14 +10:00
#include "ptcl.h"
Continue building out pipeline Plumbs the new tiling scheme to k4. This works (stroke only) but still has some performance issues.
2020-06-04 02:28:43 +10:00
#include "tile.h"
Initial implementation of blend modes * Add blend and composition mode enums to API * Mirror these in the shaders * Add new public blend function to PietGpuRenderContext that mirrors clip * Plumb the modes through the pipeline from scene to kernel4
2022-03-01 04:38:14 +11:00
#include "blend.h"
Add draft kernel 4 Render from ptcl rather than original scene.
2020-04-22 12:30:14 +10:00
Remove manual blend stack spilling and rely on scratch memory instead v2: Add a panic when the nested blend depth exceeds the limit. v3: Rebase and partially remove code introduced in 22507de.
2021-03-30 14:59:49 +11:00
#define MAX_BLEND_STACK 128
use mediump precision for kernel4 colors and areas Improves kernel4 performance for a Gio scene from ~22ms to ~15ms. Updates #83 Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-04-20 02:56:57 +10:00
mediump vec3 tosRGB(mediump vec3 rgb) {
More blend mode fixes Adds a test to visualize the blend modes. Fixes a dumb bug in blend.h and also a more subtle issue where default blending is not the same as clipping, as the former needs to always push a blend group (to cause isolation) and the latter does not. This might be something we need to get back to. This should fix the rendering, so it fairly closely resembles the Mozilla reference image. There's also a compile-time switch to disable sRGB conversion, which is (sadly) needed for compatible rendering.
2022-05-18 07:34:14 +10:00
#if DO_SRGB_CONVERSION
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
bvec3 cutoff = greaterThanEqual(rgb, vec3(0.0031308));
shaders: Add .clang-format and reformat Helps keeping the code tidy. Style is chosen to minimize diff, but contains a slight bit of personal taste.
2022-01-30 18:23:18 +11:00
mediump vec3 below = vec3(12.92) * rgb;
mediump vec3 above = vec3(1.055) * pow(rgb, vec3(0.41666)) - vec3(0.055);
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
return mix(below, above, cutoff);
More blend mode fixes Adds a test to visualize the blend modes. Fixes a dumb bug in blend.h and also a more subtle issue where default blending is not the same as clipping, as the former needs to always push a blend group (to cause isolation) and the latter does not. This might be something we need to get back to. This should fix the rendering, so it fairly closely resembles the Mozilla reference image. There's also a compile-time switch to disable sRGB conversion, which is (sadly) needed for compatible rendering.
2022-05-18 07:34:14 +10:00
#else
return rgb;
#endif
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
}
use mediump precision for kernel4 colors and areas Improves kernel4 performance for a Gio scene from ~22ms to ~15ms. Updates #83 Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-04-20 02:56:57 +10:00
mediump vec3 fromsRGB(mediump vec3 srgb) {
More blend mode fixes Adds a test to visualize the blend modes. Fixes a dumb bug in blend.h and also a more subtle issue where default blending is not the same as clipping, as the former needs to always push a blend group (to cause isolation) and the latter does not. This might be something we need to get back to. This should fix the rendering, so it fairly closely resembles the Mozilla reference image. There's also a compile-time switch to disable sRGB conversion, which is (sadly) needed for compatible rendering.
2022-05-18 07:34:14 +10:00
#if DO_SRGB_CONVERSION
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
// Formula from EXT_sRGB.
bvec3 cutoff = greaterThanEqual(srgb, vec3(0.04045));
shaders: Add .clang-format and reformat Helps keeping the code tidy. Style is chosen to minimize diff, but contains a slight bit of personal taste.
2022-01-30 18:23:18 +11:00
mediump vec3 below = srgb / vec3(12.92);
mediump vec3 above = pow((srgb + vec3(0.055)) / vec3(1.055), vec3(2.4));
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
return mix(below, above, cutoff);
More blend mode fixes Adds a test to visualize the blend modes. Fixes a dumb bug in blend.h and also a more subtle issue where default blending is not the same as clipping, as the former needs to always push a blend group (to cause isolation) and the latter does not. This might be something we need to get back to. This should fix the rendering, so it fairly closely resembles the Mozilla reference image. There's also a compile-time switch to disable sRGB conversion, which is (sadly) needed for compatible rendering.
2022-05-18 07:34:14 +10:00
#else
return srgb;
#endif
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
}
// unpacksRGB unpacks a color in the sRGB color space to a vec4 in the linear color
// space.
use mediump precision for kernel4 colors and areas Improves kernel4 performance for a Gio scene from ~22ms to ~15ms. Updates #83 Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-04-20 02:56:57 +10:00
mediump vec4 unpacksRGB(uint srgba) {
mediump vec4 color = unpackUnorm4x8(srgba).wzyx;
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
return vec4(fromsRGB(color.rgb), color.a);
}
// packsRGB packs a color in the linear color space into its 8-bit sRGB equivalent.
use mediump precision for kernel4 colors and areas Improves kernel4 performance for a Gio scene from ~22ms to ~15ms. Updates #83 Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-04-20 02:56:57 +10:00
uint packsRGB(mediump vec4 rgba) {
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
rgba = vec4(tosRGB(rgba.rgb), rgba.a);
return packUnorm4x8(rgba.wzyx);
}
Create chunks over the x axis in addition to y axis This allows more coalescing with image loads/stores, since all of our images are stored with a tiled layout.
2021-03-23 22:54:49 +11:00
uvec2 chunk_offset(uint i) {
return uvec2(i % CHUNK_X * CHUNK_DX, i / CHUNK_X * CHUNK_DY);
}
use mediump precision for kernel4 colors and areas Improves kernel4 performance for a Gio scene from ~22ms to ~15ms. Updates #83 Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-04-20 02:56:57 +10:00
mediump vec4[CHUNK] fillImage(uvec2 xy, CmdImage cmd_img) {
mediump vec4 rgba[CHUNK];
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
for (uint i = 0; i < CHUNK; i++) {
Create chunks over the x axis in addition to y axis This allows more coalescing with image loads/stores, since all of our images are stored with a tiled layout.
2021-03-23 22:54:49 +11:00
ivec2 uv = ivec2(xy + chunk_offset(i)) + cmd_img.offset;
use mediump precision for kernel4 colors and areas Improves kernel4 performance for a Gio scene from ~22ms to ~15ms. Updates #83 Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-04-20 02:56:57 +10:00
mediump vec4 fg_rgba;
Start work on gradients WIP. Most of the GPU-side work should be done (though it's not tested end-to-end and it's certainly possible I missed something), but still needs work on encoding side.
2021-06-24 04:50:51 +10:00
fg_rgba = imageLoad(image_atlas, uv);
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
fg_rgba.rgb = fromsRGB(fg_rgba.rgb);
rgba[i] = fg_rgba;
}
return rgba;
}
Add draft kernel 4 Render from ptcl rather than original scene.
2020-04-22 12:30:14 +10:00
void main() {
implement variable output sizing Signed-off-by: Elias Naur <mail@eliasnaur.com>
2020-12-18 10:55:21 +11:00
uint tile_ix = gl_WorkGroupID.y * conf.width_in_tiles + gl_WorkGroupID.x;
all: add optional memory checks Defining MEM_DEBUG in mem.h will add a size field to Alloc and enable bounds and alignment checks for every memory read and write. Notes: - Deriving an Alloc from Path.tiles is unsound, but it's more trouble to convert Path.tiles from TileRef to a variable sized Alloc. - elements.comp note that "We should be able to use an array of structs but the NV shader compiler doesn't seem to like it". If that's still relevant, does the shared arrays of Allocs work? Signed-off-by: Elias Naur <mail@eliasnaur.com>
2020-12-24 22:00:53 +11:00
Alloc cmd_alloc = slice_mem(conf.ptcl_alloc, tile_ix * PTCL_INITIAL_ALLOC, PTCL_INITIAL_ALLOC);
CmdRef cmd_ref = CmdRef(cmd_alloc.offset);
Add draft kernel 4 Render from ptcl rather than original scene.
2020-04-22 12:30:14 +10:00
First cut at split blend stack Split the blend stack into register and memory segments. Do blending in registers up to that size, then spill to memory if needed. This version may regress performance on Pixel 4, as it uses common memory for the blend stack, rather than keeping that memory read-only in fine rasterization, and using a separate buffer for blend stack. This needs investigation. It's possible we'll want to have single common memory as a config option, as it pools allocations and decreases the probability of failure. Also a flaw in this version: there is no checking of memory overflow. For understanding code history: this commit largely reverts #77, but there were some intervening changes to blending, and this commit also implements the split so some of the stack is in registers. Closes #156
2022-05-17 04:01:03 +10:00
uint blend_offset = memory[cmd_ref.offset >> 2];
cmd_ref.offset += 4;
shaders: Add .clang-format and reformat Helps keeping the code tidy. Style is chosen to minimize diff, but contains a slight bit of personal taste.
2022-01-30 18:23:18 +11:00
uvec2 xy_uint = uvec2(gl_LocalInvocationID.x + TILE_WIDTH_PX * gl_WorkGroupID.x,
gl_LocalInvocationID.y + TILE_HEIGHT_PX * gl_WorkGroupID.y);
Add draft kernel 4 Render from ptcl rather than original scene.
2020-04-22 12:30:14 +10:00
vec2 xy = vec2(xy_uint);
use mediump precision for kernel4 colors and areas Improves kernel4 performance for a Gio scene from ~22ms to ~15ms. Updates #83 Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-04-20 02:56:57 +10:00
mediump vec4 rgba[CHUNK];
First cut at split blend stack Split the blend stack into register and memory segments. Do blending in registers up to that size, then spill to memory if needed. This version may regress performance on Pixel 4, as it uses common memory for the blend stack, rather than keeping that memory read-only in fine rasterization, and using a separate buffer for blend stack. This needs investigation. It's possible we'll want to have single common memory as a config option, as it pools allocations and decreases the probability of failure. Also a flaw in this version: there is no checking of memory overflow. For understanding code history: this commit largely reverts #77, but there were some intervening changes to blending, and this commit also implements the split so some of the stack is in registers. Closes #156
2022-05-17 04:01:03 +10:00
uint blend_stack[BLEND_STACK_SPLIT][CHUNK];
Output multiple pixels per thread in k4 In kernel 4, compute a chunk of pixels rather than just one per thread. This is a dramatic speedup. (This commit cherry-picked from another working branch)
2020-05-26 08:45:06 +10:00
for (uint i = 0; i < CHUNK; i++) {
kernel4: compute and output alpha Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-03-23 02:06:15 +11:00
rgba[i] = vec4(0.0);
Output multiple pixels per thread in k4 In kernel 4, compute a chunk of pixels rather than just one per thread. This is a dramatic speedup. (This commit cherry-picked from another working branch)
2020-05-26 08:45:06 +10:00
}
Add draft kernel 4 Render from ptcl rather than original scene.
2020-04-22 12:30:14 +10:00
use mediump precision for kernel4 colors and areas Improves kernel4 performance for a Gio scene from ~22ms to ~15ms. Updates #83 Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-04-20 02:56:57 +10:00
mediump float area[CHUNK];
pre-allocate kernel4 scratch space in coarse.comp coarse.comp knows the maximum stack depth, and can pre-allocate scratch space for kernel4.comp. Kernel4 no longer contains allocations nor control barriers. The invocation local blend stack is gone as well; it didn't seem to make any difference in performance to always use global memory for pushing and popping. Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-03-31 05:16:36 +11:00
uint clip_depth = 0;
Implement robust dynamic memory This is the core logic for robust dynamic memory. There are changes to both shaders and the driver logic. On the shader side, failure information is more useful and fine grained. In particular, it now reports which stage failed and how much memory would have been required to make that stage succeed. On the driver side, there is a new RenderDriver abstraction which owns command buffers (and associated query pools) and runs the logic to retry and reallocate buffers when necessary. There's also a fairly significant rework of the logic to produce the config block, as that overlaps the robust memory. The RenderDriver abstraction may not stay. It was done this way to minimize code disruption, but arguably it should just be combined with Renderer. Another change: the GLSL length() method on a buffer requires additional infrastructure (at least on Metal, where it needs a binding of its own), so we now pass that in as a field in the config. This also moves blend memory to its own buffer. This worked out well because coarse rasterization can simply report the size of the blend buffer and it can be reallocated without needing to rerun the pipeline. In the previous state, blend allocations and ptcl writes were interleaved in coarse rasterization, so a failure of the former would require rerunning coarse. This should fix #83 (finally!) There are a few loose ends. The binaries haven't (yet) been updated (I've been testing using a hand-written test program). Gradients weren't touched so still have a fixed size allocation. And the logic to calculate the new buffer size on allocation failure could be smarter. Closes #175
2022-06-24 01:48:26 +10:00
// Previously we would early-out if there was a memory failure, so we wouldn't try to read corrupt
// tiles. But now we assume this is checked CPU-side before launching fine rasterization.
while (true) {
add support for element flags to shaders Commit 9afa9b86b6b10701b977619f75211c812aa329ca added Rust support for encoding flags into elements. This change adds support to shaders by introducing variant tag structs: struct VariantTag { uint tag; uint flags; } and returning them from Variant_tag functions. It also adds a flags argument to write functions for enum variants that include TagFlags. No functionality changes. Updates #70 Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-03-17 20:51:38 +11:00
uint tag = Cmd_tag(cmd_alloc, cmd_ref).tag;
Add draft kernel 4 Render from ptcl rather than original scene.
2020-04-22 12:30:14 +10:00
if (tag == Cmd_End) {
break;
}
switch (tag) {
Implement stroked polylines This version seems to work but the allocation of segments has low utilization. Probably best to allocate in chunks rather than try to make them contiguous.
2020-04-29 04:02:19 +10:00
case Cmd_Stroke:
Shader documentation and a slight cleanup
2020-06-28 23:37:27 +10:00
// Calculate distance field from all the line segments in this tile.
all: add optional memory checks Defining MEM_DEBUG in mem.h will add a size field to Alloc and enable bounds and alignment checks for every memory read and write. Notes: - Deriving an Alloc from Path.tiles is unsound, but it's more trouble to convert Path.tiles from TileRef to a variable sized Alloc. - elements.comp note that "We should be able to use an array of structs but the NV shader compiler doesn't seem to like it". If that's still relevant, does the shared arrays of Allocs work? Signed-off-by: Elias Naur <mail@eliasnaur.com>
2020-12-24 22:00:53 +11:00
CmdStroke stroke = Cmd_Stroke_read(cmd_alloc, cmd_ref);
use mediump precision for kernel4 colors and areas Improves kernel4 performance for a Gio scene from ~22ms to ~15ms. Updates #83 Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-04-20 02:56:57 +10:00
mediump float df[CHUNK];
shaders: Add .clang-format and reformat Helps keeping the code tidy. Style is chosen to minimize diff, but contains a slight bit of personal taste.
2022-01-30 18:23:18 +11:00
for (uint k = 0; k < CHUNK; k++)
df[k] = 1e9;
Continue building out pipeline Plumbs the new tiling scheme to k4. This works (stroke only) but still has some performance issues.
2020-06-04 02:28:43 +10:00
TileSegRef tile_seg_ref = TileSegRef(stroke.tile_ref);
Use linked list strategy for segments Trying to allocate them contiguously wasn't good.
2020-04-29 15:25:57 +10:00
do {
Implement robust dynamic memory This is the core logic for robust dynamic memory. There are changes to both shaders and the driver logic. On the shader side, failure information is more useful and fine grained. In particular, it now reports which stage failed and how much memory would have been required to make that stage succeed. On the driver side, there is a new RenderDriver abstraction which owns command buffers (and associated query pools) and runs the logic to retry and reallocate buffers when necessary. There's also a fairly significant rework of the logic to produce the config block, as that overlaps the robust memory. The RenderDriver abstraction may not stay. It was done this way to minimize code disruption, but arguably it should just be combined with Renderer. Another change: the GLSL length() method on a buffer requires additional infrastructure (at least on Metal, where it needs a binding of its own), so we now pass that in as a field in the config. This also moves blend memory to its own buffer. This worked out well because coarse rasterization can simply report the size of the blend buffer and it can be reallocated without needing to rerun the pipeline. In the previous state, blend allocations and ptcl writes were interleaved in coarse rasterization, so a failure of the former would require rerunning coarse. This should fix #83 (finally!) There are a few loose ends. The binaries haven't (yet) been updated (I've been testing using a hand-written test program). Gradients weren't touched so still have a fixed size allocation. And the logic to calculate the new buffer size on allocation failure could be smarter. Closes #175
2022-06-24 01:48:26 +10:00
TileSeg seg = TileSeg_read(new_alloc(tile_seg_ref.offset, TileSeg_size, true), tile_seg_ref);
change tile segment representation to (origin, vector) Eliminates the precision loss of the subtraction in the sign(end.x - start.x) expression in kernel4. That's important for the next change that avoids inconsistent line intersections in path_coarse. Updates #23 Signed-off-by: Elias Naur <mail@eliasnaur.com>
2020-12-02 04:06:09 +11:00
vec2 line_vec = seg.vector;
Continue building out pipeline Plumbs the new tiling scheme to k4. This works (stroke only) but still has some performance issues.
2020-06-04 02:28:43 +10:00
for (uint k = 0; k < CHUNK; k++) {
change tile segment representation to (origin, vector) Eliminates the precision loss of the subtraction in the sign(end.x - start.x) expression in kernel4. That's important for the next change that avoids inconsistent line intersections in path_coarse. Updates #23 Signed-off-by: Elias Naur <mail@eliasnaur.com>
2020-12-02 04:06:09 +11:00
vec2 dpos = xy + vec2(0.5, 0.5) - seg.origin;
Create chunks over the x axis in addition to y axis This allows more coalescing with image loads/stores, since all of our images are stored with a tiled layout.
2021-03-23 22:54:49 +11:00
dpos += vec2(chunk_offset(k));
Continue building out pipeline Plumbs the new tiling scheme to k4. This works (stroke only) but still has some performance issues.
2020-06-04 02:28:43 +10:00
float t = clamp(dot(line_vec, dpos) / dot(line_vec, line_vec), 0.0, 1.0);
df[k] = min(df[k], length(line_vec * t - dpos));
Address review comments
2020-05-06 02:13:07 +10:00
}
Continue building out pipeline Plumbs the new tiling scheme to k4. This works (stroke only) but still has some performance issues.
2020-06-04 02:28:43 +10:00
tile_seg_ref = seg.next;
} while (tile_seg_ref.offset != 0);
Output multiple pixels per thread in k4 In kernel 4, compute a chunk of pixels rather than just one per thread. This is a dramatic speedup. (This commit cherry-picked from another working branch)
2020-05-26 08:45:06 +10:00
for (uint k = 0; k < CHUNK; k++) {
coarse,kernel4: make stroke, (non-zero) fill, solid separate commands Before this change, every command (FillColor, FillImage, BeginClip) had (or would need) stroke, (non-zero) fill and solid variants. This change adds a command for each fill mode and their parameters, reducing code duplication and adds support for stroked FillImage and BeginClip as a side-effect. The rest of the pipeline doesn't yet support Stroked FillImage and BeginClip. That's a follow-up change. Since each command includes a tag, this change adds an extra word for each fill and stroke. That waste is also addressed in a follow-up. Updates #70 Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-03-18 22:47:14 +11:00
area[k] = clamp(stroke.half_width + 0.5 - df[k], 0.0, 1.0);
Output multiple pixels per thread in k4 In kernel 4, compute a chunk of pixels rather than just one per thread. This is a dramatic speedup. (This commit cherry-picked from another working branch)
2020-05-26 08:45:06 +10:00
}
tightly pack fine rasterizer commands Reclaims the space waste from splitting fill mode commands from fill commands. For example, a CmdStroke + CmdColor use an extra tag word compared to the former combined CmdStroke. This change shaves off that one word. In the future, we can pack several command tags into one tag word, saving even more space. Fixes #66 Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-03-19 06:17:04 +11:00
cmd_ref.offset += 4 + CmdStroke_size;
Implement stroked polylines This version seems to work but the allocation of segments has low utilization. Probably best to allocate in chunks rather than try to make them contiguous.
2020-04-29 04:02:19 +10:00
break;
Fills Adds fills, and has more or less working tiger render (with artifacts).
2020-05-01 10:06:01 +10:00
case Cmd_Fill:
all: add optional memory checks Defining MEM_DEBUG in mem.h will add a size field to Alloc and enable bounds and alignment checks for every memory read and write. Notes: - Deriving an Alloc from Path.tiles is unsound, but it's more trouble to convert Path.tiles from TileRef to a variable sized Alloc. - elements.comp note that "We should be able to use an array of structs but the NV shader compiler doesn't seem to like it". If that's still relevant, does the shared arrays of Allocs work? Signed-off-by: Elias Naur <mail@eliasnaur.com>
2020-12-24 22:00:53 +11:00
CmdFill fill = Cmd_Fill_read(cmd_alloc, cmd_ref);
shaders: Add .clang-format and reformat Helps keeping the code tidy. Style is chosen to minimize diff, but contains a slight bit of personal taste.
2022-01-30 18:23:18 +11:00
for (uint k = 0; k < CHUNK; k++)
area[k] = float(fill.backdrop);
coarse,kernel4: make stroke, (non-zero) fill, solid separate commands Before this change, every command (FillColor, FillImage, BeginClip) had (or would need) stroke, (non-zero) fill and solid variants. This change adds a command for each fill mode and their parameters, reducing code duplication and adds support for stroked FillImage and BeginClip as a side-effect. The rest of the pipeline doesn't yet support Stroked FillImage and BeginClip. That's a follow-up change. Since each command includes a tag, this change adds an extra word for each fill and stroke. That waste is also addressed in a follow-up. Updates #70 Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-03-18 22:47:14 +11:00
tile_seg_ref = TileSegRef(fill.tile_ref);
// Calculate coverage based on backdrop + coverage of each line segment
do {
Implement robust dynamic memory This is the core logic for robust dynamic memory. There are changes to both shaders and the driver logic. On the shader side, failure information is more useful and fine grained. In particular, it now reports which stage failed and how much memory would have been required to make that stage succeed. On the driver side, there is a new RenderDriver abstraction which owns command buffers (and associated query pools) and runs the logic to retry and reallocate buffers when necessary. There's also a fairly significant rework of the logic to produce the config block, as that overlaps the robust memory. The RenderDriver abstraction may not stay. It was done this way to minimize code disruption, but arguably it should just be combined with Renderer. Another change: the GLSL length() method on a buffer requires additional infrastructure (at least on Metal, where it needs a binding of its own), so we now pass that in as a field in the config. This also moves blend memory to its own buffer. This worked out well because coarse rasterization can simply report the size of the blend buffer and it can be reallocated without needing to rerun the pipeline. In the previous state, blend allocations and ptcl writes were interleaved in coarse rasterization, so a failure of the former would require rerunning coarse. This should fix #83 (finally!) There are a few loose ends. The binaries haven't (yet) been updated (I've been testing using a hand-written test program). Gradients weren't touched so still have a fixed size allocation. And the logic to calculate the new buffer size on allocation failure could be smarter. Closes #175
2022-06-24 01:48:26 +10:00
TileSeg seg = TileSeg_read(new_alloc(tile_seg_ref.offset, TileSeg_size, true), tile_seg_ref);
coarse,kernel4: make stroke, (non-zero) fill, solid separate commands Before this change, every command (FillColor, FillImage, BeginClip) had (or would need) stroke, (non-zero) fill and solid variants. This change adds a command for each fill mode and their parameters, reducing code duplication and adds support for stroked FillImage and BeginClip as a side-effect. The rest of the pipeline doesn't yet support Stroked FillImage and BeginClip. That's a follow-up change. Since each command includes a tag, this change adds an extra word for each fill and stroke. That waste is also addressed in a follow-up. Updates #70 Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-03-18 22:47:14 +11:00
for (uint k = 0; k < CHUNK; k++) {
Create chunks over the x axis in addition to y axis This allows more coalescing with image loads/stores, since all of our images are stored with a tiled layout.
2021-03-23 22:54:49 +11:00
vec2 my_xy = xy + vec2(chunk_offset(k));
coarse,kernel4: make stroke, (non-zero) fill, solid separate commands Before this change, every command (FillColor, FillImage, BeginClip) had (or would need) stroke, (non-zero) fill and solid variants. This change adds a command for each fill mode and their parameters, reducing code duplication and adds support for stroked FillImage and BeginClip as a side-effect. The rest of the pipeline doesn't yet support Stroked FillImage and BeginClip. That's a follow-up change. Since each command includes a tag, this change adds an extra word for each fill and stroke. That waste is also addressed in a follow-up. Updates #70 Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-03-18 22:47:14 +11:00
vec2 start = seg.origin - my_xy;
vec2 end = start + seg.vector;
vec2 window = clamp(vec2(start.y, end.y), 0.0, 1.0);
if (window.x != window.y) {
vec2 t = (window - start.y) / seg.vector.y;
vec2 xs = vec2(mix(start.x, end.x, t.x), mix(start.x, end.x, t.y));
float xmin = min(min(xs.x, xs.y), 1.0) - 1e-6;
float xmax = max(xs.x, xs.y);
float b = min(xmax, 1.0);
float c = max(b, 0.0);
float d = max(xmin, 0.0);
float a = (b + 0.5 * (d * d - c * c) - xmin) / (xmax - xmin);
area[k] += a * (window.x - window.y);
}
area[k] += sign(seg.vector.x) * clamp(my_xy.y - seg.y_edge + 1.0, 0.0, 1.0);
}
tile_seg_ref = seg.next;
} while (tile_seg_ref.offset != 0);
for (uint k = 0; k < CHUNK; k++) {
area[k] = min(abs(area[k]), 1.0);
}
tightly pack fine rasterizer commands Reclaims the space waste from splitting fill mode commands from fill commands. For example, a CmdStroke + CmdColor use an extra tag word compared to the former combined CmdStroke. This change shaves off that one word. In the future, we can pack several command tags into one tag word, saving even more space. Fixes #66 Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-03-19 06:17:04 +11:00
cmd_ref.offset += 4 + CmdFill_size;
coarse,kernel4: make stroke, (non-zero) fill, solid separate commands Before this change, every command (FillColor, FillImage, BeginClip) had (or would need) stroke, (non-zero) fill and solid variants. This change adds a command for each fill mode and their parameters, reducing code duplication and adds support for stroked FillImage and BeginClip as a side-effect. The rest of the pipeline doesn't yet support Stroked FillImage and BeginClip. That's a follow-up change. Since each command includes a tag, this change adds an extra word for each fill and stroke. That waste is also addressed in a follow-up. Updates #70 Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-03-18 22:47:14 +11:00
break;
case Cmd_Solid:
for (uint k = 0; k < CHUNK; k++) {
area[k] = 1.0;
}
tightly pack fine rasterizer commands Reclaims the space waste from splitting fill mode commands from fill commands. For example, a CmdStroke + CmdColor use an extra tag word compared to the former combined CmdStroke. This change shaves off that one word. In the future, we can pack several command tags into one tag word, saving even more space. Fixes #66 Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-03-19 06:17:04 +11:00
cmd_ref.offset += 4;
coarse,kernel4: make stroke, (non-zero) fill, solid separate commands Before this change, every command (FillColor, FillImage, BeginClip) had (or would need) stroke, (non-zero) fill and solid variants. This change adds a command for each fill mode and their parameters, reducing code duplication and adds support for stroked FillImage and BeginClip as a side-effect. The rest of the pipeline doesn't yet support Stroked FillImage and BeginClip. That's a follow-up change. Since each command includes a tag, this change adds an extra word for each fill and stroke. That waste is also addressed in a follow-up. Updates #70 Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-03-18 22:47:14 +11:00
break;
case Cmd_Alpha:
CmdAlpha alpha = Cmd_Alpha_read(cmd_alloc, cmd_ref);
for (uint k = 0; k < CHUNK; k++) {
area[k] = alpha.alpha;
}
tightly pack fine rasterizer commands Reclaims the space waste from splitting fill mode commands from fill commands. For example, a CmdStroke + CmdColor use an extra tag word compared to the former combined CmdStroke. This change shaves off that one word. In the future, we can pack several command tags into one tag word, saving even more space. Fixes #66 Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-03-19 06:17:04 +11:00
cmd_ref.offset += 4 + CmdAlpha_size;
coarse,kernel4: make stroke, (non-zero) fill, solid separate commands Before this change, every command (FillColor, FillImage, BeginClip) had (or would need) stroke, (non-zero) fill and solid variants. This change adds a command for each fill mode and their parameters, reducing code duplication and adds support for stroked FillImage and BeginClip as a side-effect. The rest of the pipeline doesn't yet support Stroked FillImage and BeginClip. That's a follow-up change. Since each command includes a tag, this change adds an extra word for each fill and stroke. That waste is also addressed in a follow-up. Updates #70 Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-03-18 22:47:14 +11:00
break;
case Cmd_Color:
CmdColor color = Cmd_Color_read(cmd_alloc, cmd_ref);
use mediump precision for kernel4 colors and areas Improves kernel4 performance for a Gio scene from ~22ms to ~15ms. Updates #83 Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-04-20 02:56:57 +10:00
mediump vec4 fg = unpacksRGB(color.rgba_color);
Output multiple pixels per thread in k4 In kernel 4, compute a chunk of pixels rather than just one per thread. This is a dramatic speedup. (This commit cherry-picked from another working branch)
2020-05-26 08:45:06 +10:00
for (uint k = 0; k < CHUNK; k++) {
use mediump precision for kernel4 colors and areas Improves kernel4 performance for a Gio scene from ~22ms to ~15ms. Updates #83 Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-04-20 02:56:57 +10:00
mediump vec4 fg_k = fg * area[k];
kernel4: compute and output alpha Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-03-23 02:06:15 +11:00
rgba[k] = rgba[k] * (1.0 - fg_k.a) + fg_k;
shader: implement clip paths Expand the the final kernel4 stage to maintain a per-pixel mask. Introduce two new path elements, FillMask and FillMaskInv, to fill the mask. FillMask acts like Fill, while FillMaskInv fills the area outside the path. SVG clipPaths is then representable by a FillMaskInv(0.0) for every nested path, preceded by a FillMask(1.0) to clear the mask. The bounding box for FillMaskInv elements is the entire screen; tightening of the bounding box is left for future work. Note that a fullscreen bounding box is not hopelessly inefficient because completely filling a tile with a mask is just a single CmdSolidMask per tile. Fixes #30 Signed-off-by: Elias Naur <mail@eliasnaur.com>
2020-10-09 21:43:29 +11:00
}
tightly pack fine rasterizer commands Reclaims the space waste from splitting fill mode commands from fill commands. For example, a CmdStroke + CmdColor use an extra tag word compared to the former combined CmdStroke. This change shaves off that one word. In the future, we can pack several command tags into one tag word, saving even more space. Fixes #66 Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-03-19 06:17:04 +11:00
cmd_ref.offset += 4 + CmdColor_size;
shader: implement clip paths Expand the the final kernel4 stage to maintain a per-pixel mask. Introduce two new path elements, FillMask and FillMaskInv, to fill the mask. FillMask acts like Fill, while FillMaskInv fills the area outside the path. SVG clipPaths is then representable by a FillMaskInv(0.0) for every nested path, preceded by a FillMask(1.0) to clear the mask. The bounding box for FillMaskInv elements is the entire screen; tightening of the bounding box is left for future work. Note that a fullscreen bounding box is not hopelessly inefficient because completely filling a tile with a mask is just a single CmdSolidMask per tile. Fixes #30 Signed-off-by: Elias Naur <mail@eliasnaur.com>
2020-10-09 21:43:29 +11:00
break;
Start work on gradients WIP. Most of the GPU-side work should be done (though it's not tested end-to-end and it's certainly possible I missed something), but still needs work on encoding side.
2021-06-24 04:50:51 +10:00
case Cmd_LinGrad:
CmdLinGrad lin = Cmd_LinGrad_read(cmd_alloc, cmd_ref);
float d = lin.line_x * float(xy.x) + lin.line_y * float(xy.y) + lin.line_c;
for (uint k = 0; k < CHUNK; k++) {
vec2 chunk_xy = vec2(chunk_offset(k));
float my_d = d + lin.line_x * chunk_xy.x + lin.line_y * chunk_xy.y;
int x = int(round(clamp(my_d, 0.0, 1.0) * float(GRADIENT_WIDTH - 1)));
mediump vec4 fg_rgba = imageLoad(gradients, ivec2(x, int(lin.index)));
fg_rgba.rgb = fromsRGB(fg_rgba.rgb);
Radial gradients This patch adds radial gradients, including both the piet API and some new methods specifically to support COLRv1, including the ability to transform the gradient separately from the path.
2022-03-18 09:00:08 +11:00
mediump vec4 fg_k = fg_rgba * area[k];
rgba[k] = rgba[k] * (1.0 - fg_k.a) + fg_k;
Start work on gradients WIP. Most of the GPU-side work should be done (though it's not tested end-to-end and it's certainly possible I missed something), but still needs work on encoding side.
2021-06-24 04:50:51 +10:00
}
cmd_ref.offset += 4 + CmdLinGrad_size;
break;
Radial gradients This patch adds radial gradients, including both the piet API and some new methods specifically to support COLRv1, including the ability to transform the gradient separately from the path.
2022-03-18 09:00:08 +11:00
case Cmd_RadGrad:
CmdRadGrad rad = Cmd_RadGrad_read(cmd_alloc, cmd_ref);
for (uint k = 0; k < CHUNK; k++) {
vec2 my_xy = xy + vec2(chunk_offset(k));
my_xy = rad.mat.xz * my_xy.x + rad.mat.yw * my_xy.y - rad.xlat;
float ba = dot(my_xy, rad.c1);
float ca = rad.ra * dot(my_xy, my_xy);
float t = sqrt(ba * ba + ca) - ba - rad.roff;
int x = int(round(clamp(t, 0.0, 1.0) * float(GRADIENT_WIDTH - 1)));
mediump vec4 fg_rgba = imageLoad(gradients, ivec2(x, int(rad.index)));
fg_rgba.rgb = fromsRGB(fg_rgba.rgb);
mediump vec4 fg_k = fg_rgba * area[k];
rgba[k] = rgba[k] * (1.0 - fg_k.a) + fg_k;
}
cmd_ref.offset += 4 + CmdRadGrad_size;
break;
coarse,kernel4: make stroke, (non-zero) fill, solid separate commands Before this change, every command (FillColor, FillImage, BeginClip) had (or would need) stroke, (non-zero) fill and solid variants. This change adds a command for each fill mode and their parameters, reducing code duplication and adds support for stroked FillImage and BeginClip as a side-effect. The rest of the pipeline doesn't yet support Stroked FillImage and BeginClip. That's a follow-up change. Since each command includes a tag, this change adds an extra word for each fill and stroke. That waste is also addressed in a follow-up. Updates #70 Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-03-18 22:47:14 +11:00
case Cmd_Image:
CmdImage fill_img = Cmd_Image_read(cmd_alloc, cmd_ref);
use mediump precision for kernel4 colors and areas Improves kernel4 performance for a Gio scene from ~22ms to ~15ms. Updates #83 Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-04-20 02:56:57 +10:00
mediump vec4 img[CHUNK] = fillImage(xy_uint, fill_img);
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
for (uint k = 0; k < CHUNK; k++) {
use mediump precision for kernel4 colors and areas Improves kernel4 performance for a Gio scene from ~22ms to ~15ms. Updates #83 Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-04-20 02:56:57 +10:00
mediump vec4 fg_k = img[k] * area[k];
kernel4: compute and output alpha Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-03-23 02:06:15 +11:00
rgba[k] = rgba[k] * (1.0 - fg_k.a) + fg_k;
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
}
tightly pack fine rasterizer commands Reclaims the space waste from splitting fill mode commands from fill commands. For example, a CmdStroke + CmdColor use an extra tag word compared to the former combined CmdStroke. This change shaves off that one word. In the future, we can pack several command tags into one tag word, saving even more space. Fixes #66 Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-03-19 06:17:04 +11:00
cmd_ref.offset += 4 + CmdImage_size;
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
break;
Add transforms and state stack Actually handle transforms in RenderCtx (was implemented in renderer but not actually plumbed through). This also requires maintaining a state stack, which will also be required for clipping. This PR also starts work on encoding clipping, including tracking bounding boxes. WIP, none of this is tested yet.
2020-11-20 06:53:59 +11:00
case Cmd_BeginClip:
First cut at split blend stack Split the blend stack into register and memory segments. Do blending in registers up to that size, then spill to memory if needed. This version may regress performance on Pixel 4, as it uses common memory for the blend stack, rather than keeping that memory read-only in fine rasterization, and using a separate buffer for blend stack. This needs investigation. It's possible we'll want to have single common memory as a config option, as it pools allocations and decreases the probability of failure. Also a flaw in this version: there is no checking of memory overflow. For understanding code history: this commit largely reverts #77, but there were some intervening changes to blending, and this commit also implements the split so some of the stack is in registers. Closes #156
2022-05-17 04:01:03 +10:00
if (clip_depth < BLEND_STACK_SPLIT) {
for (uint k = 0; k < CHUNK; k++) {
blend_stack[clip_depth][k] = packsRGB(vec4(rgba[k]));
rgba[k] = vec4(0.0);
}
} else {
uint base_ix = (blend_offset >> 2) + (clip_depth - BLEND_STACK_SPLIT) * TILE_HEIGHT_PX * TILE_WIDTH_PX +
CHUNK * (gl_LocalInvocationID.x + CHUNK_DX * gl_LocalInvocationID.y);
for (uint k = 0; k < CHUNK; k++) {
Implement robust dynamic memory This is the core logic for robust dynamic memory. There are changes to both shaders and the driver logic. On the shader side, failure information is more useful and fine grained. In particular, it now reports which stage failed and how much memory would have been required to make that stage succeed. On the driver side, there is a new RenderDriver abstraction which owns command buffers (and associated query pools) and runs the logic to retry and reallocate buffers when necessary. There's also a fairly significant rework of the logic to produce the config block, as that overlaps the robust memory. The RenderDriver abstraction may not stay. It was done this way to minimize code disruption, but arguably it should just be combined with Renderer. Another change: the GLSL length() method on a buffer requires additional infrastructure (at least on Metal, where it needs a binding of its own), so we now pass that in as a field in the config. This also moves blend memory to its own buffer. This worked out well because coarse rasterization can simply report the size of the blend buffer and it can be reallocated without needing to rerun the pipeline. In the previous state, blend allocations and ptcl writes were interleaved in coarse rasterization, so a failure of the former would require rerunning coarse. This should fix #83 (finally!) There are a few loose ends. The binaries haven't (yet) been updated (I've been testing using a hand-written test program). Gradients weren't touched so still have a fixed size allocation. And the logic to calculate the new buffer size on allocation failure could be smarter. Closes #175
2022-06-24 01:48:26 +10:00
blend_mem[base_ix + k] = packsRGB(vec4(rgba[k]));
First cut at split blend stack Split the blend stack into register and memory segments. Do blending in registers up to that size, then spill to memory if needed. This version may regress performance on Pixel 4, as it uses common memory for the blend stack, rather than keeping that memory read-only in fine rasterization, and using a separate buffer for blend stack. This needs investigation. It's possible we'll want to have single common memory as a config option, as it pools allocations and decreases the probability of failure. Also a flaw in this version: there is no checking of memory overflow. For understanding code history: this commit largely reverts #77, but there were some intervening changes to blending, and this commit also implements the split so some of the stack is in registers. Closes #156
2022-05-17 04:01:03 +10:00
rgba[k] = vec4(0.0);
}
Continuing work on clips I realized there's a problem with encoding clip bboxes relative to the current transform (see #36 for a more detailed explanation), so this is changing it to absolute bboxes. This more or less gets clips working. There are optimization opportunities (all-clear and all-opaque mask tiles), and it doesn't deal with overflow of the blend stack, but it seems to basically work.
2020-11-21 04:26:02 +11:00
}
pre-allocate kernel4 scratch space in coarse.comp coarse.comp knows the maximum stack depth, and can pre-allocate scratch space for kernel4.comp. Kernel4 no longer contains allocations nor control barriers. The invocation local blend stack is gone as well; it didn't seem to make any difference in performance to always use global memory for pushing and popping. Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-03-31 05:16:36 +11:00
clip_depth++;
tightly pack fine rasterizer commands Reclaims the space waste from splitting fill mode commands from fill commands. For example, a CmdStroke + CmdColor use an extra tag word compared to the former combined CmdStroke. This change shaves off that one word. In the future, we can pack several command tags into one tag word, saving even more space. Fixes #66 Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-03-19 06:17:04 +11:00
cmd_ref.offset += 4;
Continuing work on clips I realized there's a problem with encoding clip bboxes relative to the current transform (see #36 for a more detailed explanation), so this is changing it to absolute bboxes. This more or less gets clips working. There are optimization opportunities (all-clear and all-opaque mask tiles), and it doesn't deal with overflow of the blend stack, but it seems to basically work.
2020-11-21 04:26:02 +11:00
break;
Add transforms and state stack Actually handle transforms in RenderCtx (was implemented in renderer but not actually plumbed through). This also requires maintaining a state stack, which will also be required for clipping. This PR also starts work on encoding clipping, including tracking bounding boxes. WIP, none of this is tested yet.
2020-11-20 06:53:59 +11:00
case Cmd_EndClip:
Initial implementation of blend modes * Add blend and composition mode enums to API * Mirror these in the shaders * Add new public blend function to PietGpuRenderContext that mirrors clip * Plumb the modes through the pipeline from scene to kernel4
2022-03-01 04:38:14 +11:00
CmdEndClip end_clip = Cmd_EndClip_read(cmd_alloc, cmd_ref);
pre-allocate kernel4 scratch space in coarse.comp coarse.comp knows the maximum stack depth, and can pre-allocate scratch space for kernel4.comp. Kernel4 no longer contains allocations nor control barriers. The invocation local blend stack is gone as well; it didn't seem to make any difference in performance to always use global memory for pushing and popping. Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-03-31 05:16:36 +11:00
clip_depth--;
First cut at split blend stack Split the blend stack into register and memory segments. Do blending in registers up to that size, then spill to memory if needed. This version may regress performance on Pixel 4, as it uses common memory for the blend stack, rather than keeping that memory read-only in fine rasterization, and using a separate buffer for blend stack. This needs investigation. It's possible we'll want to have single common memory as a config option, as it pools allocations and decreases the probability of failure. Also a flaw in this version: there is no checking of memory overflow. For understanding code history: this commit largely reverts #77, but there were some intervening changes to blending, and this commit also implements the split so some of the stack is in registers. Closes #156
2022-05-17 04:01:03 +10:00
uint base_ix;
Fix blend memory issues
2022-05-21 07:02:24 +10:00
if (clip_depth >= BLEND_STACK_SPLIT) {
First cut at split blend stack Split the blend stack into register and memory segments. Do blending in registers up to that size, then spill to memory if needed. This version may regress performance on Pixel 4, as it uses common memory for the blend stack, rather than keeping that memory read-only in fine rasterization, and using a separate buffer for blend stack. This needs investigation. It's possible we'll want to have single common memory as a config option, as it pools allocations and decreases the probability of failure. Also a flaw in this version: there is no checking of memory overflow. For understanding code history: this commit largely reverts #77, but there were some intervening changes to blending, and this commit also implements the split so some of the stack is in registers. Closes #156
2022-05-17 04:01:03 +10:00
base_ix = (blend_offset >> 2) + (clip_depth - BLEND_STACK_SPLIT) * TILE_HEIGHT_PX * TILE_WIDTH_PX +
CHUNK * (gl_LocalInvocationID.x + CHUNK_DX * gl_LocalInvocationID.y);
}
Add transforms and state stack Actually handle transforms in RenderCtx (was implemented in renderer but not actually plumbed through). This also requires maintaining a state stack, which will also be required for clipping. This PR also starts work on encoding clipping, including tracking bounding boxes. WIP, none of this is tested yet.
2020-11-20 06:53:59 +11:00
for (uint k = 0; k < CHUNK; k++) {
First cut at split blend stack Split the blend stack into register and memory segments. Do blending in registers up to that size, then spill to memory if needed. This version may regress performance on Pixel 4, as it uses common memory for the blend stack, rather than keeping that memory read-only in fine rasterization, and using a separate buffer for blend stack. This needs investigation. It's possible we'll want to have single common memory as a config option, as it pools allocations and decreases the probability of failure. Also a flaw in this version: there is no checking of memory overflow. For understanding code history: this commit largely reverts #77, but there were some intervening changes to blending, and this commit also implements the split so some of the stack is in registers. Closes #156
2022-05-17 04:01:03 +10:00
uint bg_rgba;
if (clip_depth < BLEND_STACK_SPLIT) {
bg_rgba = blend_stack[clip_depth][k];
} else {
Implement robust dynamic memory This is the core logic for robust dynamic memory. There are changes to both shaders and the driver logic. On the shader side, failure information is more useful and fine grained. In particular, it now reports which stage failed and how much memory would have been required to make that stage succeed. On the driver side, there is a new RenderDriver abstraction which owns command buffers (and associated query pools) and runs the logic to retry and reallocate buffers when necessary. There's also a fairly significant rework of the logic to produce the config block, as that overlaps the robust memory. The RenderDriver abstraction may not stay. It was done this way to minimize code disruption, but arguably it should just be combined with Renderer. Another change: the GLSL length() method on a buffer requires additional infrastructure (at least on Metal, where it needs a binding of its own), so we now pass that in as a field in the config. This also moves blend memory to its own buffer. This worked out well because coarse rasterization can simply report the size of the blend buffer and it can be reallocated without needing to rerun the pipeline. In the previous state, blend allocations and ptcl writes were interleaved in coarse rasterization, so a failure of the former would require rerunning coarse. This should fix #83 (finally!) There are a few loose ends. The binaries haven't (yet) been updated (I've been testing using a hand-written test program). Gradients weren't touched so still have a fixed size allocation. And the logic to calculate the new buffer size on allocation failure could be smarter. Closes #175
2022-06-24 01:48:26 +10:00
bg_rgba = blend_mem[base_ix + k];
First cut at split blend stack Split the blend stack into register and memory segments. Do blending in registers up to that size, then spill to memory if needed. This version may regress performance on Pixel 4, as it uses common memory for the blend stack, rather than keeping that memory read-only in fine rasterization, and using a separate buffer for blend stack. This needs investigation. It's possible we'll want to have single common memory as a config option, as it pools allocations and decreases the probability of failure. Also a flaw in this version: there is no checking of memory overflow. For understanding code history: this commit largely reverts #77, but there were some intervening changes to blending, and this commit also implements the split so some of the stack is in registers. Closes #156
2022-05-17 04:01:03 +10:00
}
mediump vec4 bg = unpacksRGB(bg_rgba);
New clip implementation This PR reworks the clip implementation. The highlight is that clip bounding box accounting is now done on GPU rather than CPU. The clip mask is also rasterized on EndClip rather than BeginClip, which decreases memory traffic needed for the clip stack. This is a pretty good working state, but not all cleanup has been applied. An important next step is to remove the CPU clip accounting (it is computed and encoded, but that result is not used). Another step is to remove the Annotated structure entirely. Fixes #88. Also relevant to #119
2022-02-18 11:25:41 +11:00
mediump vec4 fg = rgba[k] * area[k];
Fix blending math The blending math had two errors: first, colors were not separated for the purpose of blending (blending was wrongly applied to premultiplied values), and second, alpha was applied over-aggressively to the alpha channel. This PR does *not* address the issue of gamma correctness. That is a complex issue and should probably be handled in the short term by disabling sRGB conversions and doing the internal math in sRGB color space rather than linear. This will degrade the quality of antialiasing but on the other hand give spec-compliant results for compositing. We remove the plus-darker mode as its specification does not appear to be valid. The plus-lighter mode remains as it is quite useful for cross-fading effects. Also the generated shaders were compiled on mac so the DXIL is unsigned. Those should be compiled on Windows before this PR is merged. (and we should figure out a better strategy for all that)
2022-05-14 03:18:29 +10:00
rgba[k] = mix_blend_compose(bg, fg, end_clip.blend);
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
}
Initial implementation of blend modes * Add blend and composition mode enums to API * Mirror these in the shaders * Add new public blend function to PietGpuRenderContext that mirrors clip * Plumb the modes through the pipeline from scene to kernel4
2022-03-01 04:38:14 +11:00
cmd_ref.offset += 4 + CmdEndClip_size;
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
break;
Dynamic allocation of intermediate buffers When the initial allocation is exceeded, do an atomic bump allocation. This is done for both tilegroup instances and per tile command lists.
2020-04-26 03:15:22 +10:00
case Cmd_Jump:
all: add optional memory checks Defining MEM_DEBUG in mem.h will add a size field to Alloc and enable bounds and alignment checks for every memory read and write. Notes: - Deriving an Alloc from Path.tiles is unsound, but it's more trouble to convert Path.tiles from TileRef to a variable sized Alloc. - elements.comp note that "We should be able to use an array of structs but the NV shader compiler doesn't seem to like it". If that's still relevant, does the shared arrays of Allocs work? Signed-off-by: Elias Naur <mail@eliasnaur.com>
2020-12-24 22:00:53 +11:00
cmd_ref = CmdRef(Cmd_Jump_read(cmd_alloc, cmd_ref).new_ref);
cmd_alloc.offset = cmd_ref.offset;
kernel4: replace continue in switch to support D3D11 shader model 5.0 Without this change, the fxc.exe compiler complains error X3708: continue cannot be used in a switch Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-04-12 03:54:40 +10:00
break;
Add draft kernel 4 Render from ptcl rather than original scene.
2020-04-22 12:30:14 +10:00
}
}
Output multiple pixels per thread in k4 In kernel 4, compute a chunk of pixels rather than just one per thread. This is a dramatic speedup. (This commit cherry-picked from another working branch)
2020-05-26 08:45:06 +10:00
for (uint i = 0; i < CHUNK; i++) {
Mostly working rendering This exposes interfaces to render glyphs into a texture atlas. The main changes are: * Methods to plumb raw Metal GPU resources (device, texture, etc) into piet-gpu-hal objects. * A new glyph_render API specialized to rendering glyphs. This is basically the same as just painting to a canvas, but will allow better caching (and has more direct access to fonts, bypassing the Piet font type which is underdeveloped). * Ability to render to A8 target in addition to RGBA. WIP, there are some rough edges, not least of which is that the image format changes are only on mac and cause compile errors elsewhere.
2022-01-20 06:58:01 +11:00
#ifdef GRAY
// Just store the alpha value; later we can specialize this kernel more to avoid
// computing unneeded RGB colors.
imageStore(image, ivec2(xy_uint + chunk_offset(i)), vec4(rgba[i].a));
#else
kernel4: compute and output alpha Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-03-23 02:06:15 +11:00
imageStore(image, ivec2(xy_uint + chunk_offset(i)), vec4(tosRGB(rgba[i].rgb), rgba[i].a));
Mostly working rendering This exposes interfaces to render glyphs into a texture atlas. The main changes are: * Methods to plumb raw Metal GPU resources (device, texture, etc) into piet-gpu-hal objects. * A new glyph_render API specialized to rendering glyphs. This is basically the same as just painting to a canvas, but will allow better caching (and has more direct access to fonts, bypassing the Piet font type which is underdeveloped). * Ability to render to A8 target in addition to RGBA. WIP, there are some rough edges, not least of which is that the image format changes are only on mac and cause compile errors elsewhere.
2022-01-20 06:58:01 +11:00
#endif
Output multiple pixels per thread in k4 In kernel 4, compute a chunk of pixels rather than just one per thread. This is a dramatic speedup. (This commit cherry-picked from another working branch)
2020-05-26 08:45:06 +10:00
}
Add draft kernel 4 Render from ptcl rather than original scene.
2020-04-22 12:30:14 +10:00
}
Reference in a new issue Copy permalink