oneDNN Graph API - lack of catchall pattern for operators

[RichardLFord]

I am trying to use the oneDNN Graph API for a machine learning model. We are doing an external partitioning of our operator graph into parts that are supported by the oneDNN graph API ( according to its documentation) and parts that are not. Then we will send the subgraphs that are supposedly supported by the oneDNN Graph API to it.

For the purpose of unit testing, we want to be able to create graphs with single operators, for each of the graph API operators that we are using.

However, when I make a graph that has only a single StaticReshape, or a single StaticTranspose, a call to partition.is_supported() fails.

In studying the logic of partitioning, it appears that partitions are chosen using passes.

Each pass has a chance to look at the remaining unpartitioned operators and decide if it can handle them. If so, then it creates a partition, moving the matching operators to the partition.

This continues until there are no unmatched operators. 

However, it appears that if the dnnl backend (or others, if there are others) passes leave some operators unmatched, then a "fake backend" will match the remainder. 

Then the check for whether a partition is supported checks to see if it is using the fake backend.

In looking at the existing patterns in the dnnl backend, it does not appear that the patterns are exhaustive. This is inconvenient because it appears that operators are usable in some contexts, but not in others.

I don't know if I am missing something, but it appears that there needs to be a catch-all pattern that runs after all of the others have run. This pattern would, at a minimum, match single remaining operators, make a partition for them, and then use a kernel that could execute that single operator. 

Thanks for your help.

Richard L. Ford

[IntelSupport]

Hi Richard,

Thank you for contacting Intel® Support. Your case will be triaged by an engineer in a timely manner. 

[yehudaorel]

Hi Richard, seems like there is ongoing discussion with regarding this topic via oneDNN github - https://github.com/oneapi-src/oneDNN/issues/1858

Closing this thread to avoid duplication.