Remove target ids from kdb args

[cderb]

Target ids are removed from the -mcpu argument for the kernel object entries. This argument now only contains the architecture string.
This resolves a bug where MIOpen is unable to find these objects while querying the kdb.

[atamazov]

@cderb AFAIU there should be corresponding changes in the library, right? Could you provide a link to the relevant PR? Thanks!

Another question is about other targets - gfx906/900, gfx103X/110X, gfx904X. Do we need the same changes in kdbs for them?

[cderb]

@cderb AFAIU there should be corresponding changes in the library, right? Could you provide a link to the relevant PR? Thanks!

@atamazov no corresponding MIOpen change this time, @JehandadKhan discovered that some of our kernels haven't been loading.

Another question is about other targets - gfx906/900, gfx103X/110X, gfx904X. Do we need the same changes in kdbs for them?

It looks like gfx906 could require the change as well, but gfx1030 and gfx900 are safe

[atamazov]

@JehandadKhan @cderb

Target ids are removed from the -mcpu argument for the kernel object entries.

If you mean target features like xnack and sramecc then we must be careful. These features affect code generation in the compiler. Simplified:

• If a GPU reports XNACK feature then the code generated without xnack will likely work incorrectly.
• If a GPU does not report XNACK then the code generated with xnack may work slower than it potentially can.
• If a GPU reports SRAMECC feature then the code generated without sramecc will likely work incorrectly.
• If a GPU does not report SRAMECC then the code generated with sramecc may work slower than it potentially can.

Therefore the kernels should be build with correctly specified target features and the target features should be used for fetching kernels from kdb.

IIRC ROC runtime prevents loading of kernels that do not have correct target feature attributes.

This is just to remind -- maybe you are aware of all this stuff.

[cderb]

@atamazov
Tuna was adding for example '-mcpu=gfx90a:sram-ecc+:xnack-' onto the end of kernel argument lists for exported dbs. And this was based purely off the arch string.
MIOpen would search for the kernel arguments explicitly and it expected '-mcpu=gfx90a'.
The targetid isn't normally incorporated in this string, so it was added in error. The string in these dbs has been reduced to '-mcpu=gfx90a' etc.

[atamazov]

@cderb Thanks for feedback. I've looked into MIOpen code and see the following:

• Devices with different XNACK or SRAMECC attributes are assumed to have different ISA and therefore MIOpen uses different KDB files. Some part of KDB filename is taken TargetProperties::DbId().
  • Discussion can be found at Add support for Target Features (resolves SWDEV-263677) #674 (comment)
• As you are saying, MIOpen does not add target features to the KDB queries. That is correct because we have different KDBs for different combinations of target features.

I think that this PR is correct. I only wondering how system KDB worked before ;)