* Make sure source strings are terminated
The source strings may or may not have a null terminator. We need to
make sure we add one before outputting the source strings as we iterate
over the c-str looking for the null terminator.
* Review feedback
As reported in #1624, Ubuntu 14.04 LTS still uses CMake 2.8.12 which
does not support the Threads::Threads target (added in CMake 3.1).
This could be reverted once the required CMake version is bumped to 3.1+.
Would typically be pthreads.
Without this, '-Wl,--no-undefined' would output these errors:
/usr/bin/ld: OSDependent/Unix/libOSDependent.a(ossource.cpp.o): in function `glslang::OS_CleanupThreadData()':
/home/akien/Mageia/Sandbox/_rpm/BUILD/glslang-7.10.2984/glslang/OSDependent/Unix/ossource.cpp:83: undefined reference to `__pthread_register_cancel'
/usr/bin/ld: /home/akien/Mageia/Sandbox/_rpm/BUILD/glslang-7.10.2984/glslang/OSDependent/Unix/ossource.cpp:93: undefined reference to `__pthread_unregister_cancel'
/usr/bin/ld: OSDependent/Unix/libOSDependent.a(ossource.cpp.o): in function `glslang::OS_AllocTLSIndex()':
/home/akien/Mageia/Sandbox/_rpm/BUILD/glslang-7.10.2984/glslang/OSDependent/Unix/ossource.cpp:122: undefined reference to `pthread_key_create'
/usr/bin/ld: OSDependent/Unix/libOSDependent.a(ossource.cpp.o): in function `glslang::OS_SetTLSValue(void*, void*)':
/home/akien/Mageia/Sandbox/_rpm/BUILD/glslang-7.10.2984/glslang/OSDependent/Unix/ossource.cpp:137: undefined reference to `pthread_setspecific'
/usr/bin/ld: OSDependent/Unix/libOSDependent.a(ossource.cpp.o): in function `glslang::OS_FreeTLSIndex(void*)':
/home/akien/Mageia/Sandbox/_rpm/BUILD/glslang-7.10.2984/glslang/OSDependent/Unix/ossource.cpp:162: undefined reference to `pthread_key_delete'
/usr/bin/ld: OSDependent/Unix/libOSDependent.a(ossource.cpp.o): in function `glslang::InitGlobalLock()':
/home/akien/Mageia/Sandbox/_rpm/BUILD/glslang-7.10.2984/glslang/OSDependent/Unix/ossource.cpp:175: undefined reference to `pthread_mutexattr_init'
/usr/bin/ld: /home/akien/Mageia/Sandbox/_rpm/BUILD/glslang-7.10.2984/glslang/OSDependent/Unix/ossource.cpp:176: undefined reference to `pthread_mutexattr_settype'
/usr/bin/ld: OSDependent/Unix/libOSDependent.a(ossource.cpp.o): in function `glslang::OS_GetTLSValue(void*)':
/home/akien/Mageia/Sandbox/_rpm/BUILD/glslang-7.10.2984/glslang/OSDependent/Unix/ossource.cpp:149: undefined reference to `pthread_getspecific'
including SPV generation using SPV_EXT_fragment_invocation_density.
This is an alias of the functionality in SPV_NV_shading_rate, and thus in some
cases we can only have one set of the tokens present (switch statements), so
we have picked the EXT version. This required updating the expected test
results for SPV_NV_shading_rate.
Also updated the known-good for spirv-headers so that the validator in
spirv-tools knows about the new extension.
This change adds unary conversion folding when the source is a constant.
This fixes an ISV issue whereby:
```
const float16_t f = float16_t(42.0);
```
Wouldn't compile because the conversion operator would always produce an
EvqTemporary when it could have produced an EvqConst.
I've also added a test case that proves out that all basic-type to
basic-type conversions work.
If a block has assigned a XfbOffset it is assumed that it would
inherit the current global XfbBuffer. This commit fixes two use cases:
1) Getting the members of a Block with a XfbOffset to be assigned an
offset, as explained on GLSL 4.60 spec, section "4.4.2 Output
Layout Qualifiers", subsection "Transform Feedback Layout
Qualifiers".
2) Compute properly an error on overlapping ranges if a block is
assigned a XfbOffset and one of it members is assigned a explicit
one. This gets working because when the members of a block get
assigned a Offset/Buffer at fixBlockXfbOffsets, then the block is
deassigned the Offsets, so ranges are computed only with the block
members.
BTW, this is already done when redeclaring block builtins.
Fixes#1535
If the out variable is a struct type, with a xfb_offset explicitly
assigned, the members need to get their xfb_offset assigned. This is
specially relevant, as we cannot use layout qualifiers on struct
members.
UniformAndStorageBuffer8BitAccess capability.
When using the 8-bit storage extension it basically always used the
`UniformAndStorageBuffer8BitAccess` capability, even in cases where it
wasn't required. For instance if we are targeting Vulkan 1.1 (SPIR-V 1.3
or higher), and we are only using 8-bit types in an SSBO, we only need
the `StorageBuffer8BitAccess` capability.
I fixed this by enabling storage buffer use in Vulkan 1.1 / SPIR-V 1.3
or higher, and then changing the logic to match.
I also added some tests that will output different capabilities when run
on Vulkan 1.0 and 1.1, thus they are added twice to the test list (one
for each version).
Fixes#1539
- Emit relevant capability/extension for use of perprimitiveNV in fragment shader
- Remove redundant checks for mesh shader qualifiers in glslang.y
- Add profile version check for use of extension GL_NV_mesh_shader
- Add a new gtest for use of perprimitiveNV in fragment shader
