Releases: google/graphicsfuzz
v1.3
v1.2.1
This is a bug-fix release that fixes a problem in the test case reduction component of GraphicsFuzz whereby a semantics-preserving reduction could in fact change the semantics of a shader.
In addition, the release incorporates:
- optimizations to the reducer to make it produce a smaller final result;
- additional ways to represent the constants 0 and 1 in an opaque manner during test generation;
- a fix to the GLSL worker for MacOS.
v1.2
Noteworthy features in this release:
-
Cross-platform, headless worker for Vulkan. We now use Amber to render shader jobs on Vulkan. Amber can be compiled for Windows, Linux and Android.
-
Support for compute shaders. The generator, worker and reducer now support compute shader jobs, our samples include compute shaders suitable for use with GraphicsFuzz, and our walkthrough explains how to generate, run and reduce compute shader jobs.
-
Faster test case reduction. We have worked on optimizing the test case reduction algorithm, and have found it to be generally quite a bit faster.
-
More robust image diffing. The histogram-based image comparison has been improved to take the alpha channel into account, and we have included an additional “fuzzy diff” image comparator inspired by the way images are compared in dEQP. Having results from both comparators is useful in deciding how clear-cut image differences are.
In addition, the release includes a number of bug fixes, improvements to test generation, and more robust support for Windows.
Caveats and limitations:
-
Amber needs to be built from source. In our previous release we bundled as many third-party dependencies as possible. We do not currently do this for Amber. It should be straightforward to build it from source for Windows, Linux and Android.
-
The Amber Vulkan worker is missing a few features that our legacy worker has. We intend to address these shortcomings in due course. In the meantime, our legacy Vulkan worker for Android, which does not have these shortcomings, is still available. The shortcomings are:
- When a shader job fails, we cannot yet ask Amber at what stage the failure occurred (compiling, linking or rendering), though it is often obvious from the output that we capture.
- We cannot yet use Amber to efficiently detect non-deterministic rendering.
- The --skip-render option, which is useful to avoid conducting needless rendering when reducing compile-time failure bugs, does not always work reliably: we have found a few shader compiler failures where, unless we instruct Amber to proceed all the way to rendering, the compilation error is not reported.
-
Compute shaders are not supported in the Web UI. You can launch compute shaders via the Web UI, but right now must inspect their results using command line tools (described in the walkthrough).
-
Reduction can still be slow. Test-case reduction is a hard problem and our improvements will not change its speed by an order of magnitude. Some notes on this:
- If you find a very large shader that triggers a particular issue (e.g. a crash) and find that reduction is slow, it could be worth doing more fuzzing in case the fuzzer can find a significantly smaller shader that exposes the same problem - reducing that smaller shader might be a lot faster.
- Another option in the case of a slow reduction is to use a smaller step limit than the default and see whether the final, incompletely-reduced shader is small enough to be useful for debugging purposes.
-
shader_translator can exhaust memory under Windows. Glsl-generate uses glslangValidator and shader_translator to validate shaders. An issue where shader_translator can consume a lot of memory remains open. As a work-around, glsl-generate tool has a --disable-shader-translator option that can be used to disable the use of shader_translator (which is only used to sanity-check generated shaders for validity in any case, and glslangValidator will still be used for that purpose).