diff options
| author | Tim Foley <tfoleyNV@users.noreply.github.com> | 2019-05-22 09:58:19 -0700 |
|---|---|---|
| committer | jsmall-nvidia <jsmall@nvidia.com> | 2019-05-22 12:58:19 -0400 |
| commit | 06e1ab6982df097727b74174d5b39a7f27c2dae3 (patch) | |
| tree | b6eff701534108dd863a8948c1fc3732f3db69d6 /source/core/slang-stream.cpp | |
| parent | 3247174cdb00836435794e3f07daad70bc92b66f (diff) | |
Translate .Load() to imageLoad() for Vulkan (#967)
* Translate .Load() to imageLoad() for Vulkan
We were already emitting calls to `imageLoad()` and `imageStore` when a `RWTexture*` was used with `operator[]`:
```hlsl
RWTexture2D<float> myTex;
...
float value = myTex[xy]; // becomes an imageLoad
myTex[xy] = value; // becomes an imageStore
```
However, we were *not* correctly handling the translation of an explicit `.Load()` operation:
```hlsl
float value = myTex.Load(xy);
```
The `.Load()` operation was being translated to a GLSL `texelFetch` as it would be a for a `Texture2D`, and not to an `imageLoad()` as would make sense for a `RWTexture2D` (which becomes a GLSL `image2D`).
This fix is confined to the stdlib, and is mostly a matter of emitting either `texelFetch` or `imageLoad` as the GLSL function name depending on the "access" of the resource type. It is messy code, but straightforward.
One extra detail was that there had been logic to emit a `, 0` argument in the `texelFetch` calls in the non-read-only case, because `texelFetch` usualy requires an explicit mip-level argument and `.Load()` on a `RWTexture*` doesn't recieve an LOD parameter. This is a non-issue now that we are calling `imageLoad()` instead, because `imageLoad` doesn't need/want the extra argument.
* fixup: change test baseline based on recent GLSL output changes
* fixup: review feedback
Diffstat (limited to 'source/core/slang-stream.cpp')
0 files changed, 0 insertions, 0 deletions
