<feed xmlns='http://www.w3.org/2005/Atom'>
<title>slang.git/tests/metal/8bit-vector-types.slang, branch master</title>
<subtitle>Making it easier to work with shaders</subtitle>
<id>https://git.yummers.dev/slang.git/atom?h=master</id>
<link rel='self' href='https://git.yummers.dev/slang.git/atom?h=master'/>
<link rel='alternate' type='text/html' href='https://git.yummers.dev/slang.git/'/>
<updated>2025-09-30T18:21:27+00:00</updated>
<entry>
<title>Enable metal tests (#8446)</title>
<updated>2025-09-30T18:21:27+00:00</updated>
<author>
<name>James Helferty (NVIDIA)</name>
<email>jhelferty@nvidia.com</email>
</author>
<published>2025-09-30T18:21:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.yummers.dev/slang.git/commit/?id=8086adc90b69f3199767c0617e2c429ce6b27f67'/>
<id>urn:sha1:8086adc90b69f3199767c0617e2c429ce6b27f67</id>
<content type='text'>
Enables all tests/metal/ tests that can be easily enabled.

These tests were not originally designed as render tests; they are
generally being enabled for pipecleaning purposes, and will not be
rigorously testing the corresponding funcitonality.

Where they cannot be enabled as render tests, and a metallib test wasn't
already enabled, a metallib test was enabled instead (where possible).

Fixes #7892</content>
</entry>
<entry>
<title>Fix Metal 8-bit vector type names: emit char/uchar instead of int8_t/uint8_t (#8223)</title>
<updated>2025-08-26T18:58:44+00:00</updated>
<author>
<name>Copilot</name>
<email>198982749+Copilot@users.noreply.github.com</email>
</author>
<published>2025-08-26T18:58:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.yummers.dev/slang.git/commit/?id=4e9ee1dc80ce353640c1e2134249a1f93da9229a'/>
<id>urn:sha1:4e9ee1dc80ce353640c1e2134249a1f93da9229a</id>
<content type='text'>
The Metal backend was generating incorrect type names for 8-bit vector
types, causing compilation failures when targeting Metal. According to
the Metal specification, 8-bit vector types should be named `charN` and
`ucharN` (e.g., `char2`, `uchar3`) rather than `int8_tN` and `uint8_tN`.

## Problem

When compiling Slang code with 8-bit vector types for Metal, the
compiler would emit:
```metal
uint8_t2 _S8 = uint8_t2(uint8_t(0U), uint8_t(16U));
int8_t3 _S9 = int8_t3(int8_t(0), int8_t(16), int8_t(48));
```

But the Metal compiler expects:
```metal
uchar2 _S8 = uchar2(uint8_t(0U), uint8_t(16U));
char3 _S9 = char3(int8_t(0), int8_t(16), int8_t(48));
```

This caused errors like:
```
error: unknown type name 'uint8_t2'; did you mean 'uint8_t'?
```

## Solution

Modified `MetalSourceEmitter::emitSimpleTypeImpl()` to emit the correct
Metal-specific type names for 8-bit types:
- `kIROp_Int8Type` now emits `char` instead of `int8_t`
- `kIROp_UInt8Type` now emits `uchar` instead of `uint8_t`

This change only affects the Metal backend and ensures that vector types
like `int8_t2`, `uint8_t3`, etc. are correctly emitted as `char2`,
`uchar3`, etc.

## Testing

- Added a new test case `tests/metal/8bit-vector-types.slang` to verify
the fix
- Re-enabled the previously disabled Metal test in
`tests/hlsl-intrinsic/countbits8.slang`
- Updated `tests/metal/byte-address-buffer.slang` to expect the correct
type names
- Verified that existing Metal tests continue to pass

Fixes #8211.

&lt;!-- START COPILOT CODING AGENT TIPS --&gt;
---

💡 You can make Copilot smarter by setting up custom instructions,
customizing its development environment and configuring Model Context
Protocol (MCP) servers. Learn more [Copilot coding agent
tips](https://gh.io/copilot-coding-agent-tips) in the docs.

---------

Co-authored-by: copilot-swe-agent[bot] &lt;198982749+Copilot@users.noreply.github.com&gt;
Co-authored-by: bmillsNV &lt;163073245+bmillsNV@users.noreply.github.com&gt;</content>
</entry>
</feed>
