A problem with the current spec is that BAB loads in DXIL are marked as a i32. This means that it's ultimately up to the driver to decide to do either the "safe" or the "logical" thing. If the user inputs -1 then the driver has to make the decision if they mean 0xFFFFFFFF or -1. Some vendors in the wild choose to safeguard and discard negative values, while others (such as WARP) reinterpret it as u32 instead.
Load2 has a similar issue, but this one is marked in the spec as uint even though according to Jesse, it behaves the same under the hood (so it's an i32/ambiguous too).
The proper solution imo is to add a 64-bit BAB.Load which will allow not just 4GiB buffers, but also beyond that (up to 40 bit).
A problem with the current spec is that BAB loads in DXIL are marked as a i32. This means that it's ultimately up to the driver to decide to do either the "safe" or the "logical" thing. If the user inputs -1 then the driver has to make the decision if they mean 0xFFFFFFFF or -1. Some vendors in the wild choose to safeguard and discard negative values, while others (such as WARP) reinterpret it as u32 instead. Load2 has a similar issue, but this one is marked in the spec as
uinteven though according to Jesse, it behaves the same under the hood (so it's an i32/ambiguous too). The proper solution imo is to add a 64-bit BAB.Load which will allow not just 4GiB buffers, but also beyond that (up to 40 bit).