gfauto is currently geared towards generating Amber tests. It would be useful to give it the ability to generate ShaderTrap tests, in order to be able to test GL and GLES drivers.
Currently gfauto has a fuzz_glsl_test file, which has most of the logic for the fuzzing process, and fuzz_spirv_test, which provides the ability to test using spirv-fuzz. fuzz_spirv_test uses quite a lot of the logic in fuzz_glsl_test.
Adding a ShaderTrap back-end without first refactoring could make things rather messy, so I propose the following pathway:
For now, the ShaderTrap back-end will use the existing .json shader job format.
@paulthomson for info.
gfauto is currently geared towards generating Amber tests. It would be useful to give it the ability to generate ShaderTrap tests, in order to be able to test GL and GLES drivers.
Currently gfauto has a
fuzz_glsl_testfile, which has most of the logic for the fuzzing process, andfuzz_spirv_test, which provides the ability to test using spirv-fuzz.fuzz_spirv_testuses quite a lot of the logic infuzz_glsl_test.Adding a ShaderTrap back-end without first refactoring could make things rather messy, so I propose the following pathway:
fuzz_glsl_testandfuzz_spirv_testto call themfuzz_glsl_amber_testandfuzz_spirv_amber_test, extracting any common code into a newfuzz_test_utilfile, so that neitherfuzz_glsl_amber_testnorfuzz_spirv_amber_testdepends on the other.fuzz_glsl_shadertrap_test.fuzz_test_utilshould be common to both the Amber and ShaderTrap back-ends. If it is, no action is required. Otherwise think about having afuzz_amber_test_utilfile with the Amber-specific common code.For now, the ShaderTrap back-end will use the existing
.jsonshader job format.@paulthomson for info.