https://github.com/shader-slang/slang
Revision 7f7864e80e8b5631ba5ec1aa9657fdaf1b4adb06 authored by Tim Foley on 21 June 2017, 17:43:25 UTC, committed by Tim Foley on 21 June 2017, 18:59:51 UTC
The catch with these operations is that they return a vector based on the scalar of the element type of the texture. That is, given `Texture2D<float> t` the operation `t.GatherRed(...)` should return a `float4`. The ideal way to solve this would use associated types, but we aren't there yet, so I am using extension declarations. An extension can "capture" the identity of the element type, like so: __generic<T, let N : int> __extension Texture2D<vector<T,N> > { ... } That extension will match `Texture2D<float3>` and correctly capture `T == float`, so that we can use it in other operations. Getting this working required a bunch of changes: - Actually emit the relevant extension declarations in the stdlib - Fix the parser to be able to parse `Texture2D<vector<T,N> >` (that is, a nested generic app). - I actually went ahead and significantly overhauled the expression parser while I was there, because I just couldn't deal with the existing code any longer. - Added support for general-case lookup to look through `__extension` declarations. I had logic in place to special-case this for looking up "constructors" but hadn't done anything for general member lookup yet. - This required some annoying holes to be punched through the layers, because lookup might need to invoke semantic analysis to ensure that an extension has been checked. - There is some first-pass code trying to support looking up a `typedef` nested inside the `vector` type. This is a nice idea in principle, but the problem is that the `Texture2D<T>` definition would be looking up `T.Element` and not `float4.Element`, and that means we'd need machinery for doing lookup *through* interface conformances for a type parameter like `T` The big gotcha here is that none of this logic applies to `Texture2D<float>` (the original case I mentioned) because I am matching vector types and not scalars. Matching scalars *should* be as easy as: __generic<T : __BuitlinScalarType> __extension Texture2D<T> { ... } But I'd need to confirm that interface constraints like that actually work, or else that extension would *also* apply to `Texture2D<float4>` and break everything.
1 parent 5148c59
Tip revision: 7f7864e80e8b5631ba5ec1aa9657fdaf1b4adb06 authored by Tim Foley on 21 June 2017, 17:43:25 UTC
Support texture `Gather*()` operations
Support texture `Gather*()` operations
Tip revision: 7f7864e
File | Mode | Size |
---|---|---|
build | ||
examples | ||
external | ||
source | ||
tests | ||
tools | ||
.gitignore | -rw-r--r-- | 247 bytes |
.gitmodules | -rw-r--r-- | 107 bytes |
LICENSE | -rw-r--r-- | 1.1 KB |
README.md | -rw-r--r-- | 1.5 KB |
appveyor.yml | -rw-r--r-- | 1.5 KB |
slang.h | -rw-r--r-- | 29.1 KB |
slang.sln | -rw-r--r-- | 6.3 KB |
test.bat | -rw-r--r-- | 1.4 KB |
![swh spinner](/static/img/swh-spinner.gif)
Computing file changes ...