google / amber Goto Github PK

AmberScript's buffer type is confusing.

I feel that we should have the following buffer types:

• color for color attachment of framebuffer
• depth stencil for depth/stencil attachment of framebuffer
• vertex for vertex buffer
• index for index buffer
• storage image
• sampled image
• combined image sampler
• uniform texel buffer
• storage texel buffer
• storage buffer
• uniform buffer
• input attachment

Note that here we also uses the term 'buffer' for image because in the view of Amber script, the image is also a sequence of bytes.

Since storage image, sampled image, combined image sampler, uniform texel buffer, storage texel buffer, storage buffer, uniform buffer, and input attachment are Vulkan specific descriptor types and I am not sure WebGPU will define the same types or not, we would better consider how to support buffers of WebGPU efficiently.

Implement DoPatchParameterVertices in the dawn engine.

Implement the AddRequirement method in the Dawn engine.

Implement SetBuffer in the dawn engine.

These pipeline commands are not implemented as I don't understand what values they accept. Do we even need them?

Add support for OPENCL-C shaders, probably through clspv.

Implement DoProbe in the Dawn engine.

Does it mean:

• I can never use this object again? If so then I'd call it Destroy()
• Reset() . -- I can revive this object by re-initializing it?

It means never use again. For anything in Shutdown() that doesn't require error checking we can probably move it to the Destructor. Shutdown is there so we can error check the closing of our resources (similar to the Initialize() for startup).

Reading these methods I forget what Host/Device are. Should we rename them to CopyToGPU and CopyFromGPU?

Draw after sending vertex data to vertex buffer is not guaranteed currently, as well as probe after copying frame buffer to host accessible buffer.
We must add memory barrier for safety.

Make sure everything builds and works on Windows. (This does not include the Dawn backend at this time).

Implment DoClear, DoClearDepth, DoClearStencil and DoClearColor in the Dawn engine.

Implement DoBuffer in the Dawn Engine.

Image layout of FrameBuffer should be color attachment optimal when clear or draw on it.
It should be transfer src optimal when copy it back to host visible buffer.

Implement the DoEntryPoint command in the Dawn engine.

It works fine when we turn on VK_LAYER_LUNARG_core_validation.
Running it without validation layer stops with timeout.

Add support to Dawn engine for the DoDrawRect command.

Implement the DoTolerance command in the Vulkan engine.

If some libraries in third_party/ are already installed in the system, current Amber build adopts the system library instead of the one in third_party/ and it can lead to build errors.

The following log shows arguments for src/amberscript/parser_test.cc:

[6/7] /usr/bin/c++  -DAMBER_ENGINE_DAWN=0 -DAMBER_ENGINE_VULKAN=1 -I../../include
-I../../ -I../../third_party/spirv-tools/include -isystem /usr/local/include -isystem
../../third_party/googletest/googletest/include -I../../third_party/shaderc/libshaderc/include
-I../../third_party/glslang/SPIRV/.. -I../../third_party/glslang/SPIRV/../External
-I../../third_party/glslang/glslang/.. -I../../third_party/spirv-headers/include -isystem
../../third_party/googletest/googletest -std=c++11
-Wall -Werror -Wextra -Wno-unknown-pragmas -Wpedantic -pedantic-errors -g
-Wno-global-constructors -fno-exceptions -fno-rtti -pthread -MD -MT 
src/CMakeFiles/amber_unittests.dir/amberscript/parser_test.cc.o -MF 
src/CMakeFiles/amber_unittests.dir/amberscript/parser_test.cc.o.d -o 
src/CMakeFiles/amber_unittests.dir/amberscript/parser_test.cc.o -c ../../src/amberscript/parser_test.cc

-isystem /usr/local/include is shown before -isystem ../../third_party/googletest/googletest/include.

If gtest/gtest.h exists in /usr/local/include, it will be used instead of third_party/googletest/googletest/include.

However, the build will try to link it with the one in third_party/ and it can lead to unreferenced symbols.

Implement the DoDrawRect command in the vulkan engine.

Add parsing for the buffer commands in amber script.

We currently uses tiling optimal for all images.
Images with optimal tiling contains data that is not readable by CPU.
We should always create secondary buffer for image to handle optimal tiling.

Implement DoPatchParameterVertices in the vulkan engine.

Many classes in src/vulkan uses protected member variables.
It results in confusing the ownership.
Make them as private and support Get/Set methods.

There is an un-implemented command line option to the amber script to dump image data, this should be implemented.

The vulkan engine currently asserts in places where things should never happen. We should probably return in these cases so that amber can be used as a library if desired.

There is an un-implemented flag to the amber script to dump buffer data, this should be implemented.

According to the VkRunner README the draw commands are only executed when a probe command is encountered. So if you have something like:

ssbo 0 subdata vec3 0 1 2 3
draw rect
ssbo 0 subdata vec3 0 5 6 7
probe

The draw rect command will use the 5 6 7 values and not the 1 2 3 values.

We have to decide if we want to follow this behaviour or go with a more expected draw executes when it's seen so draw would use 1 2 3 not 5 6 7.

Implement the DoDrawArrays command in the vulkan engine.

Setup bots to run automatically on each PR.

As far as I understand, PipelineData will be used for only graphics pipeline because it only has setups for graphics pipeline e.g., topology, polygon mode, cull mode.

I think we can remove it from ComputeCommand.

Use the entry point specified in the entry_point command for each shader.

The fbsize _width_ _height_ command has been added to vkrunner and should be added into our parsing as well.

Add SetShader support to the Dawn backend.

When working with the CTS the preference is to pre-compile all of the shaders, and send that blob over to the device. We need to support this in Amber.

There are two sides to this 1- generating the oracle 2- consuming the oracle.

For 1, we add a --oracle option to the amber application which will loop over all of the test cases, parse them, pull out the pipelines and compile the shaders as needed. It will generate a SHA of the shader source + spirv-opt options used during the compilation. This will then be written out to a file as SPIRV-HEX in a format like:

SHADER <sha>
 ... hex bytes ...
END

one block for each shader we compiled. (This also has the benefit of de-duplicating any shaders which use the same options to spirv-opt like the passthrough shader).

For 2, we update the amber application such that you can pass in the path to an Oracle, it will get read and when ShaderCompiler runs it will pull the shader from the Oracle instead of compiling.

Oracle class would be something like

Oracle:
  GenerateID(shader, options) ... outputs sha
  FindShader(shader, options) ... outputs hex bytes
  Load(string data)   ... loads oracle data from given string
  string Record()     ... writes data the string

We then put something into the API to allow you to Load and Record oracle data.

I actually think for the (shader, options) flags we want to pass in Pipeline and define an actual pipeline object like AmberScript will have. We force the creation for VkScript as needed.

The buffer size for a given ssbo, uniform or uniform ubo is defined to be the largest size seen in the script. This isn't currently possible in Amber as you won't have the last SSBO command when you see the first one.

So, I think we need to add a pre-pass over the commands in Amber to sum the size of each type of buffer and send that data to the engine to declare the various buffers of the correct sizes.

We currently link in shaderc to compile GLSL shaders. We should add the option to build in DXC as well to compile HLSL shaders.

Add support to building Amber with the NDK and executing on Android.

If you see tests/cases/probe_without_clear_command.expect_fail.amber, we expect it fails with "FrameBuffer::ChangeFrameImageLayout new layout cannot be kProbe from kInit" message.

We should check the error messages for tests that we expect failures.

Implement DoTolerance in the Dawn engine.

Implement the buffer commands in the vulkan engine.

Implement DoCompute in the Dawn engine.

Implement DoDrawArrays in the Dawn engine.

We implemented Shutdown() methods of classes but did not call them at the end of execution.