Add ComputeDerivativeGroup*NV capabilities to trim capabilities pass.

[s-perron]

No description provided.

[Keenuts]

I think this is incomplete:

 If neither derivative group mode was specified, the derivatives return zero.

Seems like removing the execution mode, but having the capability does have an effect: it allows the sampling instructions in GLCompute.
So if such instruction is used in a compute shader, but the capability is removed, we'd produce the wrong module no?

[s-perron]

I think this is incomplete:

 If neither derivative group mode was specified, the derivatives return zero.

Seems like removing the execution mode, but having the capability does have an effect: it allows the sampling instructions in GLCompute. So if such instruction is used in a compute shader, but the capability is removed, we'd produce the wrong module no?

I missed that statement in the spec. When I tried cases without the execution mode the validator complained:

~/test » spirv-val t.spv                                                                                                                                                                                                                               stevenperron@stevenperron-cloudtop
error: line 11: OpEntryPoint Entry Point <id> '1[%1]'s callgraph contains function <id> '1[%1]', which cannot be used with the current execution modes:
Derivative instructions require DerivativeGroupQuadsNV or DerivativeGroupLinearNV execution mode for GLCompute execution model: DPdx

  %1 = OpFunction %void None %5

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
~/test » spirv-dis t.spv                                                                                                                                                                                                                           1 ↵ stevenperron@stevenperron-cloudtop
; SPIR-V
; Version: 1.3
; Generator: Khronos SPIR-V Tools Assembler; 0
; Bound: 8
; Schema: 0
               OpCapability ComputeDerivativeGroupQuadsNV
               OpCapability ComputeDerivativeGroupLinearNV
               OpCapability Shader
               OpExtension "SPV_NV_compute_shader_derivatives"
               OpMemoryModel Logical GLSL450
               OpEntryPoint GLCompute %1 "main"
       %void = OpTypeVoid
      %float = OpTypeFloat 32
    %float_0 = OpConstant %float 0
          %5 = OpTypeFunction %void
          %1 = OpFunction %void None %5
          %6 = OpLabel
          %7 = OpDPdx %float %float_0
               OpReturn
               OpFunctionEnd

[s-perron]

In fact, that has been the behaviour since the validation for the extension was first implemented by Nvidia: bac82f4#diff-1232a89db063a58c947bb0e253a3161c55e2c5e49666aa96d55aaa6d59b0f8fdR78-R90

[s-perron]

@dgkoch @jmacnak-nv Do either of you have any insight into the difference between the spec and the validator?

[s-perron]

@Keenuts I suggest we merge this, since this behaviour matches the validator, and we have not heard anything from NV. I have opened up a follow up issue.

[Keenuts]

As long as the validator refuses to accept cases where we might remove the extension when required, that's fine for me.

[dgkoch]

I'm looking at this now. I don't have any insight into the current validation support though, and the original author is no longer at NVIDIA.

[dgkoch]

Seems like removing the execution mode, but having the capability does have an effect: it allows the sampling instructions in GLCompute. So if such instruction is used in a compute shader, but the capability is removed, we'd produce the wrong module no?

I missed that statement in the spec. When I tried cases without the execution mode the validator complained:

I agree that the validator seems be missing support for this, based on the above, and it does seem to contravene the spec. Not sure how important that functionality would be to keep, but it does mirror the language from the GLSL spec:

https://github.com/KhronosGroup/GLSL/blob/master/extensions/nv/GLSL_NV_compute_shader_derivatives.txt#L159

The "derivative_group_quadsNV" and "derivative_group_linearNV" qualifiers
are used to specify how compute shader invocations are grouped for the
purposes of evaluating derivatives for derivative functions and automatic
texture level of detail computation.  It is a compile-time error if both
qualifiers are specified.  If neither qualifier is specified, derivatives
evaluated for compute shaders will return zero.

[Keenuts]

LGTM for the change.
Now, it's up to you how to handle the validator issue.
Since both GLSL and the SPIR-V spec are consistent, maybe fixing the validator to correctly handle this case could be useful, but if this is required to unblock something, I'm fine with this temporary solution until it's rewritten with the validation rule.