Michael Ludwig

[graphite] Plumb TextureProxyView through read/upload codepaths In order for readbacks to be correct, they need the swizzle since the colortype is sometimes ambiguous. the actual read/upload paths don't use the swizzle in this CL (preserving old behavior) but this makes that information available for when it can switch to using TextureFormatXferFn. One change to make this easier was to have DrawContext always create its TextureProxyView with the read swizzle for its associated color type. It used to only include the view when it was sampleable, but the swizzle is also needed for copies. Whether or not it can be sampled/textured is cached on the DrawContext. This had to be cached because it involves a Caps query and some of the code that branched on whether or not it could have an image view of the DrawContext's target wouldn't always have access to Caps. If we push the texture usage bitmask into TextureInfo, then that dependence on Caps could go away in a follow up CL. Bug: b/390473370 Change-Id: Ic7b30d1e170ad66e44f28c88cf13d5a25b093c0f Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1197216 Reviewed-by: Nicolette Prevost <nicolettep@google.com> Commit-Queue: Michael Ludwig <michaelludwig@google.com>

Add R16_float_SkColorType This takes https://review.skia.org/1165337 and updates it to account for the new TextureFormatTest and APIs that are replacing the old format+colortype tables. It also fixes the angle-d3d11 failures that caused the original to be reverted marking ioFormat.fRequiresImplementationReadQuery = !GR_IS_GR_GL(standard); It also adds a mapping for storing r16f color data in a luminance 16f texture (analogous to the existing alpha-16f option). Bug: b/494552359 Change-Id: I5a66544ad44c9e71c53161b5eece704f2f63f0bc Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1191616 Reviewed-by: Kaylee Lubick <kjlubick@google.com> Reviewed-by: Nicolette Prevost <nicolettep@google.com> Commit-Queue: Michael Ludwig <michaelludwig@google.com>

[graphite] Add isOpaque to PrecompileShader This follows a similar approach to the isAlphaUnchanged function added to PrecompileColorFilter. Most shaders could be directly implemented without impacting their number of combinations. The exceptions to this are solid colors and gradients, which now have 2x the number of intrinsic combinations to represent where the color (or all the colors for gradients) are opaque. Similar to PrecompileColorFilters::Matrix, this increases the combinations evaluated but does not necessarily trigger a change in the number of final paint keys (definitely not right now, but possibly impacts the final blend decision in follow-up CLs). Bug: b/478239991 Change-Id: I5871fcc274a143e611ce61100c693c5db9b3a90a Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1225737 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Robert Phillips <robertphillips@google.com>

[graphite] Consolidate upload code around UploadSource The two UploadInstance factories were nearly identical, accounting for some assumptions around subrects vs. full rects and adding an identity TextureFormatXferFn that can run over compressed data. This makes UploadInstance created from an UploadSource, and makes UploadSource the arbiter of whether or not a transfer is valid (no more passing around duplicate parameters). UploadSource is also now the sole handler of the upload-on-host code path, and it no longer magically happens when appending to any UploadList. There are distinct times when upload-on-host makes sense and others where we really do want the task to be in the graph and the Recording. This also patches up a race condition that could have happened in Graphite-Vulkan by requiring that the TextureProxy be uniquely held and shareability of the resource won't have it aliased to other proxies. Technically this was low risk anyways since we require that the image layout of the texture be unknown, which really only happens if we haven't used the texture yet for anything. Bug: b/333909822 Change-Id: I4a32c7034775ad96fd43cc4dc2839e0a59c03bab Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1221678 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Nicolette Prevost <nicolettep@google.com> Reviewed-by: Robert Phillips <robertphillips@google.com>

[ganesh] Use submitted proc to confirm async reads were issued Ganesh's finish proc doesn't have a status, but if flushSurface() failed for unrelated reasons (due to queued operations before the asyncRead was requested), the finish proc would be executed without actually submitting the copy command to the GPU. This tracks whether or not it was successfully submitted and makes that a requirement before handing the result to the original callback. The code is updated to more closely match Graphite's structure, including unmapping any buffers on failure. Bug: 513340227 Change-Id: If2998749a754d114b70e26e312a9a4cb08ea20e2 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1242617 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Greg Daniel <egdaniel@google.com>

[graphite] Track precompile paint key opacity Bug: b/478239991 Change-Id: I81f9fd5183e60fdd0d5ac618a97677b099bb9dfb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1225738 Reviewed-by: Robert Phillips <robertphillips@google.com> Commit-Queue: Michael Ludwig <michaelludwig@google.com>

[graphite] Flesh out texture format data transfer unit tests This adds unit tests that for every texture format + compatible color type, it tests a upload from every SkColorType and a readback to every SkColorType. It adds code to generate input pixel values based on a span of Channels, using fixed values for each channel name (e.g. red = 1/15, green = 2/15, blue = 4/15, etc.), while accounting for the different channel data type encodings and loss of precision when going between different types. This allows us to also generate an expected outcome pixel value of the transfer that is defined entirely by the dst's list of channels and a swizzle to apply. The swizzle is not defined manually because it there are about 4800 combinations being generated by this unit test. Instead both the texture format and color type channel definitions include an effective swizzle. This is combined with the expected read/write swizzle of the format+colortype combination to produce the actual swizzle used when generating the expected pixel value. The "actual" pixel value is currently implemented by a stub implementation that relies entirely on SkRasterPipeline (see `transfer_data`), but this serves as a good way to test the data generation and in a follow-up CL it will be replaced with a new transfer function API that is defined to convert data to/from an SkColorType (CPU-side) and a format+swizzle (GPU-side). Bug: b/390473370 Change-Id: I07f055497964da6d8ea2269ad80066f62b1d4bea Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1187636 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Robert Phillips <robertphillips@google.com> Reviewed-by: Nicolette Prevost <nicolettep@google.com>

[graphite] CoverageMaskShape stores mask-to-device transform This simplifies some of the atlas logic flow inside drawGeometry() because once the atlas provides a CoverageMaskShape it can be recorded as if it were a regular fill. The return type of the PathAtlas is also simpler, and importantly, the CoverageMaskShape is now completely self-descriptive from a "geometric" sense. The draw's local-to-device transform is now only used to affect shading. This also fixes a subtle bug where the 4x4 device-to-local matrix was being uploaded as if it were the 3x3 inverse of the flattened local to device matrix, which is not the case when there's perspective or Z manipulation. Bug: b/445976767 Bug: b/502265025 Change-Id: Icf5b96751adfc39293ecc4331fbd912f245112d9 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1123837 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Nicolette Prevost <nicolettep@google.com>

[graphite] Move read/write swizzle lookup out of Caps The Caps::getReadSwizzle(ct, format) and getWriteSwizzle(ct, format) are moved to static functions defined in TextureFormat.cpp. These are also written to primarily look at the color channel masks so that there isn't a need to handle lookup tables like the old system. The write swizzle function now also returns an optional to be able to define the renderability between a color type and texture format. Bug: b/390473370 Change-Id: Id4caa5c8405320805a8cef157278fdbb2b050d1b Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1177797 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Robert Phillips <robertphillips@google.com>

[graphite] Lift colortype to format choice out of backends Adds a new PreferredFormatForColorType static function that takes an SkColorType and removes the temporary `Caps::getFormatForColorType()` function that took a color type and Renderable. The PreferredFormatForColorType does not need to be filtered on renderability. Instead, the Caps::getDefaultSampledTextureInfo() impl filters the returned span by whether or not the WriteSwizzleForCT function returns a non-empty swizzle. We could have the definition of PreferredFormatForColorType have two separate tables, one for renderable and one for non-renderable, which would make the getDefaultSampledTextureInfo() function simpler but at the expense of two nearly identical lookup tables. The details of the PreferredFormatForColorType lookup table is the union of all the different backend's setColorType() blocks from their format table initialization. The internal `Caps::getDefaultTextureInfo` function is updated to iterate over a span of texture formats to automatically use the first that is supported. Bug: b/390473370 Change-Id: I554a1b6a09bbcc64d5bf732bc563e2cb8d0db286 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1165836 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Robert Phillips <robertphillips@google.com>

[graphite] WrapTexture does not require SkColorType, can force opaque for any color type Adds a version of SkImages::WrapTexture that does not take a color type. It infers the color type of the created SkImage from the texture format and possibly from the alpha type. In most cases, the color type should always be the base color type of the texture. We allow kUnknown_SkAlphaType to add an RGB1 swizzle and then be changed to kOpaque_SkAlphaType. If there is a corresponding RGBx colortype in this case, we adjust from the base color type to that RGBx colortype. In the case of red-only textures, they are used for red colortypes and alpha-only colortypes. R8 is also used for gray. We disambiguate red vs. alpha-only colortype choice based on whether or not the alpha type is alpha-y (unpremul/premul == alpha-only, opaque/unknown == red). The current limitation of this is that there's no way to take an R8 texture and interpret it as a gray8 colortype. The linked bug has several options for how this might be addressed in the future. My preferred approach is to accept a backendtextureview that encodes the swizzle, in which case these WrapTexture() calls still do not need to take the SkColorType in as a parameter. Detecting "gray" via the swizzle is consistent with how TextureFormatXferFn behaves. Bug: b/476410476 Bug: b/498213682 Change-Id: I2047e7fa44719a118b25683ee544daf976764ae1 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1143379 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Robert Phillips <robertphillips@google.com>

[graphite] Drop excessively large gradient draws This skips recording draws with more than 1M color stops, primarily as a way to avoid worrying about overflowing during intermediate calculations. We can increase it if necessary, but hopefully this is healthy enough no one is trying to make shaders this large. This also skips recording draws when the FSM has maxed out its allocatable size for a single buffer. Given how large that is, we shouldn't encounter it in the wild but this lets us fail semi gracefully. If needed, we can revisit by either flushing the entire Recorder when reaching a limit, or by allowing a recording to use multiple buffers Bug: 515467789 Fixed: 515467789 Change-Id: Ie032f9ed35b6cf0316a18b32bb36e3ec3c047097 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1243936 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Robert Phillips <robertphillips@google.com> Reviewed-by: Thomas Smith <thomsmit@google.com>

[graphite] Define colortype and format compatibility statically This adds two new functions to the TextureFormat header: - TextureFormatColorTypeInfo(Format) - AreColorTypeAndFormatCompatible(CT, Format) The new AreColorTypeAndFormatCompatible(CT, Format) function replaces the `Caps::areColorTypeAndFormatCompatible(ct, format)` function. The equivalent of Ganesh's areColorTypeAndFormatCompatibleAndRenderable can be handled by combining AreColorTypeAndFormatCompatible with checking if WriteSwizzleForColorType(ct, format) has a value. The implementation for AreColorTypeAndFormatCompatible derives compatibility from whether or not the color type is the "base" type of the TextureFormat or if the format is one of the preferred formats for the color type. TextureFormatColorTypeInfo() introduces a "base" color type. Every TextureFormat has a base color type, representing what its SkImageInfo would report if you were to ignore any alpha-only colortype semantics. Most formats have an exact matching SkColorType, but some do not. In that case, there is a new FormatXferOps bitmask that describes per-pixel bit manipulation operations that must be applied that cannot be described by just SkColorType <-> SkColorType conversions. For instance, a 24-bit RGB value needs to either add 0xFF in order to become a valid 32-bit RGBA/x value for SkColorType, or it needs to strip away those 8 bits to be able to upload 24bpp to the GPU. Another example is TF::BGR8_sRGB, which (in this CL) declares its base color type as kSRGBA_8888_SkColorType because the most important aspect is to declare that it has sRGB auto-encoded values. There is no kSBGRA colortype, so FormatXferOps is used to encode the RB swap and the dropping of the alpha channel. As of now, FormatXferOps are unused but it was useful to define them with the base color type to see why the base color type was chosen. The only use of the old ColorTypeInfo format tables in Caps is to define the transfer function between src and dst color types for a texture format. In a follow up CL, the FormatXferOps will be used to implement more complete set of conversion functions, and then finally the old format tables can go away. Bug: b/390473370 Change-Id: I10acb6102251a3fec4a43d922ea53b8c2ea3ff8f Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1168356 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Robert Phillips <robertphillips@google.com>

Reland "Reland "[graphite] Replicate Dawn format capability table"" This reverts commit 8106701adb3e3bec406adfb2e00ed69fbbf74e5d. Reason for revert: RGBA16F does not support MSAA in compat configs, so Device::Make was rejecting creating surfaces due to default tessellation strategy. This updates the unit test to both fail more gracefully, check for MSAA to know when it's unsupported, and add another colortype so we aren't just skipping the test on GLES. Original change's description: > Revert "Reland "[graphite] Replicate Dawn format capability table"" > > This reverts commit 57a80d08a92925d3c0eb310b4b2262f616cad682. > > Reason for revert: breaking gles builds, had been breaking on original but I missed that due to overlap with dual-source blending failures. > > Original change's description: > > Reland "[graphite] Replicate Dawn format capability table" > > > > This reverts commit c52c45b7ac78484d4f6a2a024cfb0f5b66f35040. > > > > Reason for revert: fix in PS1->PS2. The dawn-native > > Unorm16TextureFormats feature is independent of the Tier1 feature, > > so it needs to include all the renderable capabilities as well. > > > > This wasn't caught in Skia's dawn tryjobs because we enable the > > Tier1 feature, but Chrome's dawn feature requests for Graphite > > do not include Tier1 so unorm16 was only considered texturable and > > not renderable. Some code path must have been trying to render > > (perhaps for a copy-as-draw or mipmap generation). > > > > Original change's description: > > > Revert "[graphite] Replicate Dawn format capability table" > > > > > > This reverts commit 7dd4bb76cebba0ff1c859887b0d9069d858399ec. > > > > > > Reason for revert: breaking YUV 420 tests in chrome > > > > > > Original change's description: > > > > [graphite] Replicate Dawn format capability table > > > > > > > > This is similar to > > > > https://skia-review.git.corp.google.com/c/skia/+/1201016 for Metal, > > > > since both Metal and WebGPU only expose format capabilities/features as > > > > a document. The capabilities do not have a one-to-one mapping to > > > > Graphite's TextureUsage or wgpu::TextureUsage, so this adds a new enum > > > > `DawnFormatFlag` that is meant to match the HTML's table content > > > > reasonably well. These flags are then converted to Graphite's > > > > TextureUsage bitmask inside DawnCaps. > > > > > > > > Unlike in Metal, which specified each set of flags per GPU family, the > > > > wgpu::FeatureNames have a less-structured inheritance with each other > > > > (beyond core, and tier1 and 2). The Dawn tables are organized first by > > > > format and then by the features that adjust capabilities for that > > > > format. This also lines up with how the capabilities are reported in the > > > > HTML table as conditional notes with each format's row. > > > > > > > > Bug: b/390473370 > > > > Change-Id: I96df51e96235c50ef51f028aa8b84fc7c80fcd4b > > > > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1213496 > > > > Reviewed-by: Thomas Smith <thomsmit@google.com> > > > > Commit-Queue: Michael Ludwig <michaelludwig@google.com> > > > > > > Bug: b/390473370 > > > No-Presubmit: true > > > No-Tree-Checks: true > > > No-Try: true > > > Change-Id: I52f0edbf29c6e1ee2fe599f8d30f4320e3f12cbc > > > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1214737 > > > Auto-Submit: Michael Ludwig <michaelludwig@google.com> > > > Commit-Queue: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com> > > > Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com> > > > > Bug: b/390473370 > > Change-Id: Ife0a0e7fb505bfd5e8b18e234a5d9e9410e3dad6 > > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1215537 > > Reviewed-by: Thomas Smith <thomsmit@google.com> > > Commit-Queue: Michael Ludwig <michaelludwig@google.com> > > Bug: b/390473370 > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Change-Id: I7971520d0fba2d6f89a9b42c6f604e3b034d6b25 > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1217256 > Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com> > Commit-Queue: Michael Ludwig <michaelludwig@google.com> Bug: b/390473370 Change-Id: I0da1c04676c6b2cb2e30f3b48d1980a63ad9ce28 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1218121 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Robert Phillips <robertphillips@google.com> Auto-Submit: Michael Ludwig <michaelludwig@google.com>

[graphite] Remove rgba8 colortype fallback for MakeBitmapProxyView This means that SkImages::MakeTexture follows the same restrictions as SkSurfaces::RenderTarget; if the compatible texture formats aren't supported, then the SkImage will be null instead of magically changing to a format and colortype that wasn't requested (triggering on-CPU conversion during an upload or readback). A behavior consequence is that now the grdawn configs will not draw images that have a 565 or 4444 color type because there is no format representation for those colortypes in WebGPU. This may be added as an extension later (particularly around 565). Similarly, non-Apple Macs do not support these formats, so they will stop rendering in grmtl. A code consequence is that MakeBitmapProxyView doesn't have to play games with applying the alpha type swizzle to an RGBA image. This was already not the best thing to do because it would sample AAAA instead of 000A as expected, but additionally the SkImage's color type have been RGBA8, so all the shader combination logic would not add the necessary blends with the paint color (as it no longer appears alpha-only according to its color type). This alpha AAAA swizzling was really just patching up the sampling logic that was used for handling R8 vs A8 single plane images used in the YUVA shader. This CL updates that logic to detect an alpha-only swizzle or format and move it to the red channel, and removes a similar AAAA swizzle concat for YUVA from SkImage (vs. from proxies). Rerun-Tryjobs: true Bug: b/390473370 Change-Id: Iae0b48a0191fe9e4ef6db3f1e89a0c7e08466d3a Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1174659 Reviewed-by: Nicolette Prevost <nicolettep@google.com> Commit-Queue: Michael Ludwig <michaelludwig@google.com>

[graphite] Replicate Dawn format capability table This is similar to https://skia-review.git.corp.google.com/c/skia/+/1201016 for Metal, since both Metal and WebGPU only expose format capabilities/features as a document. The capabilities do not have a one-to-one mapping to Graphite's TextureUsage or wgpu::TextureUsage, so this adds a new enum `DawnFormatFlag` that is meant to match the HTML's table content reasonably well. These flags are then converted to Graphite's TextureUsage bitmask inside DawnCaps. Unlike in Metal, which specified each set of flags per GPU family, the wgpu::FeatureNames have a less-structured inheritance with each other (beyond core, and tier1 and 2). The Dawn tables are organized first by format and then by the features that adjust capabilities for that format. This also lines up with how the capabilities are reported in the HTML table as conditional notes with each format's row. Bug: b/390473370 Change-Id: I96df51e96235c50ef51f028aa8b84fc7c80fcd4b Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1213496 Reviewed-by: Thomas Smith <thomsmit@google.com> Commit-Queue: Michael Ludwig <michaelludwig@google.com>

[graphite] Simplify VulkanCaps format table initialization The FormatInfo and sample count structs are removed. Their init logic is split into 3 helper functions that are then cached in a simpler fFormatSupport double array (one per Tiling type). VulkanCommandBuffer just uses TextureFormatBytesPerBlock since VkFormatBytesPerBlock does not actually cover all VkImageFormats, but if we get into copyTextureToBuffer, it will be a VkImageFormat that maps back to a TextureFormat. Bug: b/390473370 Change-Id: I94b607ac6c8bd627bd799bbbf1189111ca107a68 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1201836 Reviewed-by: Nicolette Prevost <nicolettep@google.com> Commit-Queue: Michael Ludwig <michaelludwig@google.com>

Use 16-bit size for ResourceKeys Internally, ResourceKey required the size to fit into a uint16_t so this makes that explicit in the public API. It also changes how the size is stored to instead record the num32DataCount directly and then convert to bytes as needed, whereas previously it was requiring that the actual byte count fit into a uint16_t. This gives a bit more head room. Call sites to the ResourceKey builders are updated to now have the responsibility of checking that their size can fit into a uint16_t. For the most part, these were fixed or trivially small variable key sizes. The two exceptions were Ganesh's style key (with dashes) and its inherited key system for shapes with applied styles and path effects. They now have reasonable limits to prevent the keys from growing bigger than about 1kb. Bug: b/495700484 Change-Id: I6ac4f17628b9a2e1a777c473b74e6d1f5c68b27d Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1199497 Reviewed-by: Robert Phillips <robertphillips@google.com> Commit-Queue: Michael Ludwig <michaelludwig@google.com>

[spirv] Add MatrixStride annotations to matrix arrays Adds a new SkSL test as well to cover the case of declaring a matrix array as a uniform. Confirmed locally that without the changes to SkSLSPIRVCodeGenerator, the emitted spirv would trigger validation errors. Bug: b/496028139 Change-Id: If113d3404e2668033288e1dc2a0223319568433b Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1200417 Reviewed-by: Robert Phillips <robertphillips@google.com> Commit-Queue: Michael Ludwig <michaelludwig@google.com>

[graphite] Add support for 3-channel texture format conversions This introduces "extended" format conversion ops that make it easier to have one conversion function that doesn't care about directionality of the transfer (i.e. CPU->GPU vs. GPU->CPU). The current extended ops split FormatXferOp::kDropAlpha into a drop and a pad variant, and this CL starts to add SIMD functions for applying these operations to formats. There is no equivalent of these options in SkRasterPipeline so they have to be executed separately. This adds logic to switch to a temporary row of data that can then be processed by SkRP (or as the output of SkRP). This is an improvement over the existing code in Graphite and Ganesh, which allocates the entire 2D image to handle the 3-channel padding or dropping. In follow-up CLs, red/blue swaps and forcing alpha to opaque will be added to the extended conversions. This will be used to pull as much work out of raster pipeline (and hopefully avoid using it at all) in many typical conversions. Bug: b/390473370 Change-Id: Ie12866c7621205db74dc809423110682ec24ed5a Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1191196 Reviewed-by: Thomas Smith <thomsmit@google.com> Reviewed-by: Robert Phillips <robertphillips@google.com> Commit-Queue: Michael Ludwig <michaelludwig@google.com>