> It does, but you can always disassemble the DXBC and see what happened to your HLSL code.
And you can always disasm X86 code and see what -ffast-math did. Doesn't mean that everyone would be fine with just mandating it everywhere with no option to disable it.
Even then the DX functional spec gives some leeway. As an example if you write x*y+z it will compile it into mad instruction. And that's just specified as that the precision must not be worse as the worst possible ordering of separate instructions. So which it is? Depends on the vendor. This is completely fine for graphics, but not fine for all workloads.
> No need for manual shenanigans with command queues
Unless you do access same buffer from multiple places in a way that's still spec conformant, just in a way that the DX11 implementation cannot detect.
> Doesn't mean that everyone would be fine with just mandating it everywhere
Practically speaking, often I enable it everywhere even on CPU (or similar options in visual C++). When more precision is needed, FP64 is the way to go. Apart from rare edge cases, you won't be getting many useful mantissa bits in these denormals, or with better rounding order.
> So which it is? Depends on the vendor.
Yeah, but on the same nVidia GPU, I'm pretty sure mad in DXBC does precisely the same thing as fma in CUDA PTX.
> just in a way that the DX11 implementation cannot detect
It doesn't detect much. If you want to allow shaders to arbitrarily read and write the same buffer, bind that buffer as UAV and you'll be able to run many of these shaders in parallel, despite a single queue.
P.S. AFAIK the main use case for these queues is high-end graphics, to send relatively cheap GPU tasks at huge rate (like 1MHz of them), from many CPU cores in parallel. In GPU compute, at least in my experience, the tasks tend to be much larger.
And you can always disasm X86 code and see what -ffast-math did. Doesn't mean that everyone would be fine with just mandating it everywhere with no option to disable it.
Even then the DX functional spec gives some leeway. As an example if you write x*y+z it will compile it into mad instruction. And that's just specified as that the precision must not be worse as the worst possible ordering of separate instructions. So which it is? Depends on the vendor. This is completely fine for graphics, but not fine for all workloads.
> No need for manual shenanigans with command queues
Unless you do access same buffer from multiple places in a way that's still spec conformant, just in a way that the DX11 implementation cannot detect.