Page MenuHomePhabricator

AMDGPU: Assume xnack is enabled by default
ClosedPublic

Authored by arsenm on May 14 2019, 8:06 AM.

Details

Summary

This is the conservatively correct default. It is always safe to
assume xnack is enabled, but not the converse.

Introduce a feature to blacklist targets where xnack can never be
meaningfully enabled. I'm not sure the targets this is applied to is
100% correct.

Diff Detail

Event Timeline

arsenm created this revision.May 14 2019, 8:06 AM

Why do we have both xnack and no-xnack? I thought we are going to drop xnack feature in favor of no-xnack.

Why do we have both xnack and no-xnack? I thought we are going to drop xnack feature in favor of no-xnack.

No, my intention is to avoid having no- features, and just use +/- on the positive feature name. The new feature isn't intended for any frontends to set, and is only for marking targets in the backend where the option doesn't do anything.

rampitec accepted this revision.May 14 2019, 10:47 AM

LGTM.

We need to emphasize this change also enables xnack by default on all other targets and probably need to be complimented with FE/RT changes.

This revision is now accepted and ready to land.May 14 2019, 10:47 AM
arsenm closed this revision.May 16 2019, 7:47 AM

r360903

t-tye reopened this revision.Jan 14 2020, 7:30 AM

If this is changing the user visible defaults then the processor table in AMDGPUUsage also needs to be updated and the change of compiler needs to be mentioned in the release notes.

Only targets that do not support XNACK should be marked as DoesNotSupportXNACK which means all gfx8/9/10 should not have DoesNotSupportXNACK as they do support XNACK (as defined in the processor table of AMDGPUUsage).

If an xnack option is given on a target that doe not support XNACK it would be helpful to give a error to the user and not silently ignore the request. In particular it should not cause code object to be generated that does not have XNACK code in it yet is marked in the EFLAGS header that it does have XNACK.

This revision is now accepted and ready to land.Jan 14 2020, 7:30 AM
arsenm closed this revision.Feb 14 2020, 11:38 AM