Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
71 changes: 71 additions & 0 deletions test/Basic/matrix_single_subscript_load.test
Original file line number Diff line number Diff line change
@@ -0,0 +1,71 @@
#--- source.hlsl
RWBuffer<int> In : register(u0);
RWBuffer<int> Out : register(u1);

[numthreads(1,1,1)]
void main() {
int4x4 A = int4x4(In[0], In[1], In[2],
In[3], In[4], In[5],
In[6], In[7], In[8],
In[9], In[10], In[11],
In[12], In[13], In[14],
In[15]);
Comment on lines +7 to +12
Copy link
Contributor

@Icohedron Icohedron Nov 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Formatting nit:

Suggested change
int4x4 A = int4x4(In[0], In[1], In[2],
In[3], In[4], In[5],
In[6], In[7], In[8],
In[9], In[10], In[11],
In[12], In[13], In[14],
In[15]);
int4x4 A = int4x4(In[0], In[1], In[2], In[3],
In[4], In[5], In[6], In[7],
In[8], In[9], In[10], In[11],
In[12], In[13], In[14], In[15]);


for (int i = 0; i < 4; i++) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Why don't we follow coding standards in test? I've noticed this in lots of tests.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even in llvm-project we don't run clang-format on tests, but the capital I is a c++ coding standard for c/c++ in llvm-project. I wasn't aware we defined a coding standard for HLSL but I suppose we could adopt the c/c++ one?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah. I was referring to the c/c++ coding standard. I didn't consider that it was c/c++ specific. It's just stood out to me for the variable names in tests we add. So, my nit really was more of a question. Just stands out to me.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a slight nuance here too, which is that Clang tests often deliberately do not conform to LLVM's coding standards. It would be pretty awful if Clang only worked on C/C++ code that conformed to LLVM's standards (one could imagine a parser bug that didn't properly handle tabs because LLVM disallows them, or CRLF line endings because LLVM biases toward LF).

I don't have a strong opinion on these specific cases. I do find code easier to read if it conforms to coding standards, but there are sometimes benefits to not conform.

int4 B;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

very minor nit, but a for loop for 4 assignments with two of them be 'special' made me look at this for a moment longer.
4 explicit assignment statements might be cleaner.

if (i % 2 == 0)
B = A[i];
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a comment, not a request for change:

These subscript accesses look dynamic, but these loops are likely to be unrolled, either before IR (in DXC, Clang, etc.) or after (in a driver compiler). That unrolling would make all accesses static, even eliminating the intermediate local variables to copy values directly from static indices of In to static indices of Out. That's a fine path to test, but this might not test other important dynamic indexing code paths, if desired.

I guess this gets at the fuzzy purpose issue with the offload-test-suite. This seems fine to test this scenario end-to-end, whatever path it may take through optimizations, and maybe that's all that's desired for this test.

else if (i % 3 == 0)
B = A[i].abgr;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: abgr is also a symmetric swizzle. bagr is another asymmetric swizzle you could use.

else
B.grab = A[i];
Comment on lines +20 to +21
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Assignment swizzling is always harder to follow, but this one happens to be identical in mapping to the same swizzle if used on source instead. That seems a little too convenient, so maybe the target swizzle should be different to avoid that symmetry and make sure it's not treated the same somehow.

grab is symmetric (equivalent to grab on source):
B.grab = {5,6,7,8} -> {6,5,8,7}
B = {5,6,7,8}.grab -> {6,5,8,7}

agrb is not symmetric (equivalent to bgar on source):
B.agrb = {5,6,7,8} -> {7,6,8,5}
B = {5,6,7,8}.agrb -> {8,6,5,7}
B = {5,6,7,8}.bgar -> {7,6,8,5}

Perhaps a comment with the equivalent in source swizzle form would help too:

Suggested change
else
B.grab = A[i];
else // i == 1
B.agrb = A[i]; // equivalent: B = A[1].bgar

Corresonding update to expected values would be:

-    Data: [ 1, 2, 3, 4, 6, 5, 8, 7, 9, 10, 11, 12, 16, 15, 14, 13 ]
+    Data: [ 1, 2, 3, 4, 7, 6, 8, 5, 9, 10, 11, 12, 16, 15, 14, 13 ]

for (int j = 0; j < 4; j++) {
Out[i*4 + j] = B[j];
}
}
}
//--- pipeline.yaml

---
Shaders:
- Stage: Compute
Entry: main
DispatchSize: [1, 1, 1]
Buffers:
- Name: In
Format: Int32
Data: [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16]
- Name: Out
Format: Int32
FillSize: 64
- Name: ExpectedOut
Format: Int32
Data: [ 1, 2, 3, 4, 6, 5, 8, 7, 9, 10, 11, 12, 16, 15, 14, 13 ]
Results:
- Result: Out
Rule: BufferExact
Actual: Out
Expected: ExpectedOut
DescriptorSets:
- Resources:
- Name: In
Kind: RWBuffer
DirectXBinding:
Register: 0
Space: 0
VulkanBinding:
Binding: 0
- Name: Out
Kind: RWBuffer
DirectXBinding:
Register: 1
Space: 0
VulkanBinding:
Binding: 1
...
#--- end

# XFAIL: Clang
# RUN: split-file %s %t
# RUN: %dxc_target -T cs_6_0 -Fo %t.o %t/source.hlsl
# RUN: %offloader %t/pipeline.yaml %t.o
71 changes: 71 additions & 0 deletions test/Basic/matrix_single_subscript_store.test
Original file line number Diff line number Diff line change
@@ -0,0 +1,71 @@
#--- source.hlsl
RWBuffer<int> In : register(u0);
RWBuffer<int> Out : register(u1);

[numthreads(1,1,1)]
void main() {
int4 vec = int4(In[0], In[1], In[2],
In[3]);
Comment on lines +7 to +8
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Formatting nit

Suggested change
int4 vec = int4(In[0], In[1], In[2],
In[3]);
int4 vec = int4(In[0], In[1], In[2], In[3]);

int4x4 A;
for(int i = 0; i < 4; i++) {
if(i % 2 == 0)
A[i].rbag = vec;
// A[3] is exactly In Buffer
else if(i % 3 == 0)
A[i] = vec;
// A[1] is reverse In Buffer
else
A[i] = vec.abgr;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: another symmetric swizzle.

}
const uint COLS = 4;
for(int i = 0; i < 16; i++) {
uint row = i / COLS;
uint col = i % COLS;
Out[i] = A[row][col];
}
}
//--- pipeline.yaml

---
Shaders:
- Stage: Compute
Entry: main
DispatchSize: [1, 1, 1]
Buffers:
- Name: In
Format: Int32
Data: [ 1, 2, 3, 4]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: There is an extra space here for some reason

Suggested change
Data: [ 1, 2, 3, 4]
Data: [1, 2, 3, 4]

- Name: Out
Format: Int32
FillSize: 64
- Name: ExpectedOut
Format: Int32
Data: [ 1, 4, 2, 3, 4, 3, 2, 1, 1, 4, 2, 3, 1, 2, 3, 4 ]
Results:
- Result: Out
Rule: BufferExact
Actual: Out
Expected: ExpectedOut
DescriptorSets:
- Resources:
- Name: In
Kind: RWBuffer
DirectXBinding:
Register: 0
Space: 0
VulkanBinding:
Binding: 0
- Name: Out
Kind: RWBuffer
DirectXBinding:
Register: 1
Space: 0
VulkanBinding:
Binding: 1
...
#--- end

# XFAIL: Clang
# RUN: split-file %s %t
# RUN: %dxc_target -T cs_6_0 -Fo %t.o %t/source.hlsl
# RUN: %offloader %t/pipeline.yaml %t.o
Loading