Search Issue Tracker
Won't Fix
Votes
0
Found in
2021.3.35f1
2022.3.20f1
2023.2.10f1
2023.3.0b7
6000.0.0b11
6000.1.0a7
6000.2.0a1
Issue ID
UUM-64323
Regression
No
HLSLcc generates suboptimal code that involves meaningless double conversions
Steps to reproduce:
1. Create a new unlit shader
2. Put the following code in the fragment function:
```
int x[3][3][3] = {
{ { -1, -2, -1 }, { -2, -4, -2 }, { -1, -2, -1 } },
{ { +0, +0, +0 }, { +0, +0, +0 }, { +0, +0, +0 } },
{ { +1, +2, +1 }, { +2, +4, +2 }, { +1, +2, +1 } }
};
half4 col = tex2D(_MainTex, i.uv);
return col * half4(x[0][0][0], x[1][1][1], x[2][2][2], 1.0);
```
3. Inspect the shader code compiled for GLES3 (same code is used for Vulkan and WebGL/WebGPU).
Actual results:
The data from the array 'x' gets stored as floats using 'intBitsToFloat', then gets converted back to int using 'floatBitsToInt', then gets converted to float using the regular cast.
Expected results:
No interim conversions between bit representations happen.
Reproducible with versions:
2024.1, 2023.3, 2023.2, 2022.3, 2021.3
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Performance Markers Search window shows an empty entry in the list
- Enabling Deep Profiling in Performance Markers Search window breaks Inspector panel buttons when navigating through the marker items
- An "InvalidOperationException" error is thrown when TryRemoveItem is used with rebuildTree set to false
- Build fails with IL2CPP error when building on Android platform in a specific project
- Resize to Fit option for Import Activity window's Columns does nothing
Resolution Note:
Due to HLSLcc's architecture, this bug isn't currently fixable without significant time investment. Arrays are always represented internally as float4 arrays, and we assume as much within the codebase, meaning that we would have to endow our core data structures with more information to track an array's "actual type" to fix this issue.
Resolution Note:
Due to HLSLcc's architecture, this bug isn't currently fixable without significant time investment. Arrays are always represented internally as float4 arrays, and we assume as much within the codebase, meaning that we would have to endow our core data structures with more information to track an array's "actual type" to fix this issue.