Skip quantized recipe variants for unquantized-track EPs (VitisAI)

[KayMKM]

Problem

The vitisai_npu e2e eval leg fails on openai/clip-vit-base-patch32 / feature-extraction:

[1/2] openai/clip-vit-base-patch32 / feature-extraction [fp16]   [PASS] 206.9s
[2/2] openai/clip-vit-base-patch32 / feature-extraction [w8a16]  [FAIL (UNKNOWN)] 90.2s
    ... xir::Op{... type = quantize-linear} is partitioned to CPU as : doesn't supported by target [AMD_AIE2P_4x8_CMC_Overlay].
    ... xir::Op{... type = const-fix} is partitioned to CPU as : The op's fanout is out of DPU subgraph.
    F attrs_imp.cpp:38] Check failed: attrs_.count(key) > 0 Attrs doesn't contain attribute data
    *** Check failure stack trace: ***

A w8a16 job should never have been scheduled for VitisAI in the first place.

Root cause

The harness evaluates VitisAI on the unquantized model (_EPS_SKIP_WINML_QUANT): _resolve_precision drops any explicit precision, and both winml config and winml build receive --no-quant. That policy only covered the winml config fallback path.

In _build_jobs the quantized-variant filter was gated on not npu, so on NPU an authored recipe variant (examples/recipes/openai_clip-vit-base-patch32/feature-extraction_w8a16_config.json, weight_type: uint8 / activation_type: uint16) was still expanded into a job. _run_recipe_build cannot suppress it either — a recipe config carries its own quant section, which --no-quant does not override.

The resulting w8a16 QDQ graph is then handed to AMD_AIE2P_4x8_CMC_Overlay. VitisAI quantizes internally (XINT8) and is not meant to consume a winml-produced w8a16 QDQ graph: it partitions the quantize/dequantize and const-fix ops back to CPU and then aborts inside xir, killing the process — hence the UNKNOWN classification rather than a normal failure.

Change

• _build_jobs: filter quantized recipe variants for skip-quant EPs as well (if not npu or skip_quant). When that leaves no variant, the model falls through to the existing single unquantized winml config fallback.
• Module docstring, _EPS_SKIP_WINML_QUANT comment and scripts/e2e_eval/README.md updated to state the rule.
• Two unit tests: an fp16 + w8a16 recipe keeps only fp16 on VitisAI; a w8a16-only recipe falls back to the unquantized winml config job.

Every recipe directory under examples/recipes/ has an fp16 variant, so no model loses all of its jobs.

[DingmaomaoBJTU]

LGTM — clean, focused change. The logic generalization from not npu to not npu or skip_quant is correct and well-tested. Minor nit: the one-line docstring still says 'quant is NPU-only' which could be updated to reflect the new behavior, but not blocking.

[DingmaomaoBJTU]

LGTM — clean, focused change. The logic generalization from not npu to not npu or skip_quant is correct and well-tested. Minor nit: the one-line docstring still says 'quant is NPU-only' which could be updated to reflect the new behavior, but not blocking.