5ee05891cf
Some languages allow a restricted set of user structure types returned from texture sampling
operations. Restrictions include the total vector size of all components may not exceed 4,
and the basic types of all members must be identical.
This adds underpinnings for that ability. Because storing a whole TType or even a simple
TTypeList in the TSampler would be expensive, the structure definition is held in a
table outside the TType. The TSampler contains a small bitfield index, currently 4 bits
to support up to 15 separate texture template structure types, but that can be adjusted
up or down. Vector returns are handled as before.
There are abstraction methods accepting and returning a TType (such as may have been parsed
from a grammar). The new methods will accept a texture template type and set the
sampler to the structure if possible, checking a range of error conditions such as whether
the total structure vector components exceed 4, or whether their basic types differe, or
whether the struct contains non-vector-or-scalar members. Another query returns the
appropriate TType for the sampler.
High level summary of design:
In the TSampler, this holds an index into the texture structure return type table:
unsigned int structReturnIndex : structReturnIndexBits;
These are the methods to set or get the return type from the TSampler. They work for vector or structure returns, and potentially could be expanded to handle other things (small arrays?) if ever needed.
bool setTextureReturnType(TSampler& sampler, const TType& retType, const TSourceLoc& loc);
void getTextureReturnType(const TSampler& sampler, const TType& retType, const TSourceLoc& loc) const;
The ``convertReturn`` lambda in ``HlslParseContext::decomposeSampleMethods`` is greatly expanded to know how to copy a vec4 sample return to whatever the structure type should be. This is a little awkward since it involves introducing a comma expression to return the proper aggregate value after a set of memberwise copies.
|
||
|---|---|---|
| .. | ||
| AST.FromFile.cpp | ||
| BuiltInResource.FromFile.cpp | ||
| CMakeLists.txt | ||
| Config.FromFile.cpp | ||
| HexFloat.cpp | ||
| Hlsl.FromFile.cpp | ||
| Initializer.h | ||
| Link.FromFile.cpp | ||
| Link.FromFile.Vk.cpp | ||
| main.cpp | ||
| Pp.FromFile.cpp | ||
| README.md | ||
| Remap.FromFile.cpp | ||
| Settings.cpp | ||
| Settings.h | ||
| Spv.FromFile.cpp | ||
| TestFixture.cpp | ||
| TestFixture.h | ||
Glslang Tests based on the Google Test Framework
This directory contains Google Test based test fixture and test cases for glslang.
Apart from typical unit tests, necessary utility methods are added into
the GlslangTests fixture to provide the ability to do
file-based integration tests. Various *.FromFile.cpp files lists names
of files containing input shader code in the Test/ directory. Utility
methods will load the input shader source, compile them, and compare with
the corresponding expected output in the Test/baseResults/ directory.
How to run the tests
Please make sure you have a copy of Google Test checked out under
the External directory before building. After building, just run the
ctest command or the gtests/glslangtests binary in your build directory.
The gtests/glslangtests binary also provides an --update-mode command
line option, which, if supplied, will overwrite the golden files under
the Test/baseResults/ directory with real output from that invocation.
This serves as an easy way to update golden files.