kBufferTypeUIAlpha changed from 68 to 69 in Streamline SDK 2.12.0

[clshortfuse]

Streamline commit e8aaa6eaac968711fb62473d4ae8256dde20919b appears to introduce a public BufferType numeric compatibility break.

Observed change

Before the change:

constexpr BufferType kBufferTypeUIAlpha = 68;

After the change:

constexpr BufferType kBufferTypeResponsivityMask = 68;
constexpr BufferType kBufferTypeUIAlpha = 69;

This means an existing public constant changed numeric value.

Why this matters

BufferType values are passed as runtime data in Streamline resource tags, such as slSetTag / slSetTagForFrame ResourceTag arrays.

Applications, middleware, or compatibility layers compiled against older Streamline headers may have kBufferTypeUIAlpha baked into their binaries as raw value 68.

Newer Streamline headers now interpret raw value 68 as kBufferTypeResponsivityMask instead.

Component	Meaning of raw BufferType 68
App built with older headers	kBufferTypeUIAlpha
Streamline 2.12.0 headers	kBufferTypeResponsivityMask

Compatibility risk

Possible impact:

• Older games or integrations tagging alpha-only UI as 68 may be interpreted by newer Streamline components or tools as providing a responsivity mask.
• DLSS Frame Generation may fail to receive the intended alpha-only UI tag from older integrations.
• DLSS-D may receive a UI alpha texture where it expects a responsivity mask.
• Middleware, debugging tools, overlays, DLSS fix layers, and compatibility shims that inspect, filter, or rewrite ResourceTag arrays cannot safely decode raw BufferType 68 without knowing the exact SDK/runtime/plugin version contract.
• Newer integrations using raw 69 for UIAlpha may not be understood by older Streamline components.

Questions / request

1. Are BufferType numeric values intended to be ABI-stable across Streamline SDK versions?
2. If they are intended to be stable, can kBufferTypeUIAlpha retain value 68 and kBufferTypeResponsivityMask be assigned a new unused value instead?
3. If BufferType values are not intended to be stable, can this be explicitly documented as a breaking change?
4. Is there a recommended runtime way to disambiguate raw BufferType 68 from older binaries: legacy UIAlpha vs new ResponsivityMask?
5. Should tools/interposers assume Streamline headers, interposer DLL, plugins, and app integration must all come from the same SDK package?

Suggested compatibility-safe fix

Prefer preserving the old value:

constexpr BufferType kBufferTypeUIAlpha = 68;
constexpr BufferType kBufferTypeResponsivityMask = <new unused value>;

If preserving the old value is not possible, the changelog should call this out as an API/ABI compatibility break and provide migration guidance for interposers and middleware that handle ResourceTag arrays from existing game binaries.

[jake-nv]

Thanks for reporting this.

nvbug: 6431644