The difference between NMin and FMin is how NaN operands are handled, and NMin is needed to emulate Direct3D behaviour. If you know that your shaders don't generate NaNs, then it is safe to make the change.
Ok thanks.
BTW I also found that I have to make this change
const uint32_t stageOffset = 0; //128 + 160 * uint32_t(shaderStage);
in computeResourceSlotId to let fxc compile the generated code (otherwise it says "maximum cbuffer exceeded").
Is that made for some optimization (not for exact code translating)?
Are there other places also contains this kind of trick(?)s ?
It's not an optimization, it's done to map the D3D11 binding model to something that DXVK can more easily work with internally.
There are a lot of DXVK-specific things in the generated code since a lot of D3D11 abstractions don't exist in Vulkan at all (like append/consume buffers) or are handled differently (like raw and structured buffers), and the generated shader code will reflect that.
Ok I understand :)
Nothing extracted yet.
Hi, I am trying to use your dxbc funcs to convert some pre-compiled dx11 shaders to spirv,
then convert it back to pseudo-hlsl with spirv-cross --hlsl --shader-model 40.
The problem is spirv-cross does not process opcodes like unsupported_glsl450_nmax,nmin,nclamp.
I do not know well about shader standards actually.
So is it safe to change those nmax,nmin,nclamp in your dxbc funcs to FMax,FMin,FClamp?