Summary
get_algo_candidates() defaults to {aocl_dlp_blocked, onednn_blocked} regardless
of build configuration. Since auto_tuner is the default matmul path, the default
path cannot compute anything in a --no-aocldlp build: the tuner picks
aocl_dlp_blocked and every call fails with "requires AOCL-DLP".
An unavailable candidate is worse than merely useless here. The evaluate phase
keeps whichever candidate timed fastest, and "returned without computing" times
as near-zero — so a backend that cannot run wins the comparison and is cached as
the best algorithm for that shape.
Reproduce
--no-aocldlp build, any host:
benchdnn --op=matmul --lowoha=true --m=512 --k=512 --n=512 \
--sdt=f32 --wdt=f32 --ddt=f32 --kernel_name=auto_tuner
Fails immediately. Setting ZENDNNL_MATMUL_AUTO_ALGO_CANDIDATES="2,10" works
around it, which confirms the candidate list is the only obstacle.
Suggested fix
Select the default from what the build actually contains. Two related points found
while fixing this:
- The tuner should not time or cache a call that did not compute. The dispatch
already signals this by rewriting kernel to the AOCL-DLP marker; there are
three places that need the check, including the map seeding, where a ~0 ms seed
makes an entry unbeatable for the process lifetime.
- It should retry the next candidate rather than leave the output untouched.
Without that, a candidate list spanning backends with different dtype coverage
cannot work — the skip phase runs candidates[0] before any timing exists.
Also worth noting: the tuner bypasses should_use_mm_partitioner() entirely
(matmul_execute() handles auto_tuner and returns first), so a tuner-selected
LIBXSMM runs unpartitioned. On an A10-8770E that was 11.5 ms vs 6.9 ms for the
same shape requested by name — the tuner both measures and executes the slower
form.
Reference branch: https://github.com/lwandrebeck/BullDNN/tree/upstream/autotuner-aocl-candidates
Summary
get_algo_candidates()defaults to{aocl_dlp_blocked, onednn_blocked}regardlessof build configuration. Since
auto_tuneris the default matmul path, the defaultpath cannot compute anything in a
--no-aocldlpbuild: the tuner picksaocl_dlp_blockedand every call fails with "requires AOCL-DLP".An unavailable candidate is worse than merely useless here. The evaluate phase
keeps whichever candidate timed fastest, and "returned without computing" times
as near-zero — so a backend that cannot run wins the comparison and is cached as
the best algorithm for that shape.
Reproduce
--no-aocldlpbuild, any host:Fails immediately. Setting
ZENDNNL_MATMUL_AUTO_ALGO_CANDIDATES="2,10"worksaround it, which confirms the candidate list is the only obstacle.
Suggested fix
Select the default from what the build actually contains. Two related points found
while fixing this:
already signals this by rewriting
kernelto the AOCL-DLP marker; there arethree places that need the check, including the map seeding, where a ~0 ms seed
makes an entry unbeatable for the process lifetime.
Without that, a candidate list spanning backends with different dtype coverage
cannot work — the skip phase runs
candidates[0]before any timing exists.Also worth noting: the tuner bypasses
should_use_mm_partitioner()entirely(
matmul_execute()handlesauto_tunerand returns first), so a tuner-selectedLIBXSMM runs unpartitioned. On an A10-8770E that was 11.5 ms vs 6.9 ms for the
same shape requested by name — the tuner both measures and executes the slower
form.
Reference branch: https://github.com/lwandrebeck/BullDNN/tree/upstream/autotuner-aocl-candidates