Updated Driver In order lists check and required version

[winstonzhang-intel]

@nrspruit's patch rebased and posted here as I work on fixing this patch.

• Refactor's the check for driver in order lists into one place, but still disables driver in order lists by default.

[nrspruit]

LGTM

[nrspruit]

ok, unfortunately, it appears the command graph functionality fails if one runs with the driver in order lists enabled.

[EwanC]

ok, unfortunately, it appears the command graph functionality fails if one runs with the driver in order lists enabled.

@nrspruit I believe your previous patch had a graph test(s) fail too, I'm not sure if these are similar. We could stagger this change, so we enable in-order command lists by default (if driver version met) on the path without command-buffers, and then do a follow-on PR that enabled it for command-buffers and can resolve these graph fails?

[nrspruit]

ok, unfortunately, it appears the command graph functionality fails if one runs with the driver in order lists enabled.

@nrspruit I believe your previous patch had a graph test(s) fail too, I'm not sure if these are similar. We could stagger this change, so we enable in-order command lists by default (if driver version met) on the path without command-buffers, and then do a follow-on PR that enabled it for command-buffers and can resolve these graph fails?

That appears to be the case. @winstonzhang-intel , please update this patch to specifically disable the command graphs from using driver in order lists unless explicitly requested, but leave the default for the rest of the adapter. That will let us know if the remaining failures are limited to only the command buffers.

Then, we can work on a PR to re-enable driver in order lists for command buffers once the failures have been addressed.

[winstonzhang-intel]

ok, unfortunately, it appears the command graph functionality fails if one runs with the driver in order lists enabled.

@nrspruit I believe your previous patch had a graph test(s) fail too, I'm not sure if these are similar. We could stagger this change, so we enable in-order command lists by default (if driver version met) on the path without command-buffers, and then do a follow-on PR that enabled it for command-buffers and can resolve these graph fails?

That appears to be the case. @winstonzhang-intel , please update this patch to specifically disable the command graphs from using driver in order lists unless explicitly requested, but leave the default for the rest of the adapter. That will let us know if the remaining failures are limited to only the command buffers.

Then, we can work on a PR to re-enable driver in order lists for command buffers once the failures have been addressed.

Ok reverted back to when the tests were passing with allowDriverInOrderLists(true) in command buffer.

[nrspruit]

Because the functionality does not handle all cases of "mixing" driver in order and non-driver in order support, I don't think we can safely split this unless we do a major refactor in the event/queue code paths.

[nrspruit]

Hello @intel/llvm-gatekeepers , please merge this change when you are able. Thank you for your time!