Add QLinearConcat for DML EP

[zhangxiang1993]

[ OK ] QLinearConcatS8.ExpectFail_WrongZeroPointType_1 (372 ms)
[ RUN ] QLinearConcatS8.InputOne_Dynamic
[ OK ] QLinearConcatS8.InputOne_Dynamic (255 ms)
[ RUN ] QLinearConcatS8.InputOne_Const
[ OK ] QLinearConcatS8.InputOne_Const (255 ms)
[----------] 11 tests from QLinearConcatS8 (3385 ms total)

[----------] Global test environment tear-down
[==========] 21 tests from 3 test suites ran. (9355 ms total)
[ PASSED ] 21 tests.

[zhangxiang1993]

kernelCreationContext.GetInputEdgeDescription(OnnxInputIndex::yScale).tensorDataType

yScaleDataType #Resolved

[zhangxiang1993]

kernelCreationContext.GetInputEdgeDescription(OnnxInputIndex::yZeroPoint).tensorDataType

yZeroPointDataType #Closed

[zhangxiang1993]

kernelCreationContext.GetInputEdgeDescription(tuple_start + 1).tensorDataType

xScaleDataType #Closed

[zhangxiang1993]

kernelCreationContext.GetInputEdgeDescription(tuple_start + 2).tensorDataType

xZeroPointDataType #Resolved

[sumitsays]

Should we assign 0 as a default value to firstInputIndex parameter and remove the 2nd overloaded method? #Resolved

[sumitsays]

[nit] Should we remove this comment? #Resolved

[sumitsays]

[nit] Is there any specific reason we have used = {} to initialize this particular std::vector? #Closed

[AnaghaRaoAMD]

contribop mentions TF supports any float tensor type, should we also consider supporting fp16?

[zhangxiang1993]

I think only tensor(float) is specified, tensor(float16) is for fp16
Type Constraints
T8 : tensor(uint8), tensor(int8)
Constrain input and output types to 8 bit signed and unsigned tensors.
TF : tensor(float)
Constrain scale types to any float tensor type.
TV : tensor(uint8), tensor(int8), tensor(float)
Sequence of (Tensor, Scale, ZeroPoint) tuples. The type is sequence of (T8, TF, T8).

[fdwr]

yScale

Suggested change

	yScale,
	YScale

Consistent casing with Count. #Closed

[fdwr]

[nit] extra blank line #Closed

[fdwr]

input_def_count

inputDefinitionCount

Naming intrafile consistency. (also, DML and DML EP always use 🐪, not 🐍) #Closed

[fdwr]

tuple_start

tupleStartIndex #Resolved

[fdwr]

input_count

inputCount

etcetera... #Closed

[fdwr]

  [](http://example.com/codeflow?start=8&length=6)

[nit] 6->4 space indent.

Alternately, consider splitting the long line more readably.

        ML_CHECK_VALID_ARGUMENT(
            input_def_count >= 5 && (input_def_count - 2) % 3 == 0,
            "Each input must be (tensor, scale, zero_point) tuple!"
        );

Or better yet, splitting it into two separate conditions, which would make it much clearer the specific error to the user. Also, then the lines are not so long and don't need to wrap:

        ML_CHECK_VALID_ARGUMENT(inputDefinitionCount >= 5, "Require at least 5 inputs.");
        ML_CHECK_VALID_ARGUMENT((inputDefinitionCount - 2) % 3 == 0, "Each input must be (tensor, scale, zero_point) tuple!");

Which is like what you do below, two separate ones rather than &&ing them:

            ML_CHECK_VALID_ARGUMENT(xScaleDataType == yScaleDataType, "Wrong input type encountered for scale");
            ML_CHECK_VALID_ARGUMENT(xZeroPointDataType == yZeroPointDataType, "Wrong input type encountered for zero point");
``` #Resolved

[fdwr]

)

0 // guaranteedBaseOffsetAlignment) ->
0 // guaranteedBaseOffsetAlignment #Resolved

[fdwr]

[nit] Indent also inconsistent from all the other TensorDesc calls (8 instead of 4)

[fdwr]

Suggested change

	const DML_OPERATOR_DESC opJoinDesc{DML_OPERATOR_JOIN, &joinDesc};
	const DML_OPERATOR_DESC opJoinDesc = {DML_OPERATOR_JOIN, &joinDesc};

[nit] Consistent assignment style with nearby MLOperatorGraphDesc operatorGraphDesc = {};. #Closed

[fdwr]

Nits, but otherwise looks good Xiang.

[fdwr]

Note this function presumes the axis attribute is relative to the first input tensor (which is always the case).

Stale comment. It's not always the case anymore. #Resolved

[fdwr]

[fdwr]

TY, XZ.