Repository navigation
[Lavapipe] Mark tests affected by gallivm APInt assertion - #1580
joaosaffran wants to merge 11 commits into
Conversation
da0a186 to
bd3b087
Compare
| # Driver bug: https://github.com/llvm/offload-test-suite/issues/1553 | ||
| # UNSUPPORTED: Lavapipe |
There was a problem hiding this comment.
this is where things become unclear. because you have been using #1553 to indicate # XFAIL: Lavapipe but now you are doing # UNSUPPORTED: Lavapipe. That is a bit of inconsistency that is hard for me to wrap my head around.
There was a problem hiding this comment.
Issue #1552 is flaky, issue #1553 is not flaky. This, and some other tests, are being affected by both issues. My logic is: If a test is flaky, use UNSUPPORTED. Otherwise, if #1553 is fixed before #1552, we will see this test XPASS half the time it runs and generate noise to whoever is on triage. Let me know if there is a better approach for this.
There was a problem hiding this comment.
Can we do something like:
# Driver bug: https://github.com/llvm/offload-test-suite/issues/1552 (flakey)
# UNSUPPORTED: Lavapipe
# https://github.com/llvm/offload-test-suite/issues/1553
# XFAIL: Lavapipe
69a7238 to
bd3b087
Compare
bd3b087 to
8a88c41
Compare
8ca7acf to
8c49f95
Compare
8c49f95 to
db1828b
Compare
db1828b to
eb111e5
Compare
| # UNSUPPORTED: WARP && DXC | ||
|
|
||
| # Driver Bug: https://gitlab.freedesktop.org/api/v4/projects/mesa%2Fmesa/issues/16596 | ||
| # XFAIL: Lavapipe && AMD && DXC |
There was a problem hiding this comment.
WAIT I don't think AMD means what you think it means. AMD is a GPU. Lavapipe && AMD makes no sense it is one or the other. I think you are trying to distinguish ARM from x86 which the right way would be to look at how we do platform.machine() in lit. I see things like XFAIL: Lavapipe && host-arm64 We may need to add one for x86/x86_64.
There was a problem hiding this comment.
Yeah sorry, you are right, I made some confusion indeed. Is !host-arm64 the same as saying x86/x86_64 in this scenario?
There was a problem hiding this comment.
No it would not be. LLVM runs on RISC-V among other CPU hardwares as does lavapipe. A linux sku could technically run our offload test suite.
I would prefer if we just future proof things and explicilty check for x86.
There was a problem hiding this comment.
I've pushed this new PR to the stack: #1613, which adds the requested x86 targets
farzonl
left a comment
There was a problem hiding this comment.
All of these are some derivative of Lavapipe && AMD. That needs to be fix before you take this out of draft.
3edcd26 to
853c2ad
Compare
625425e to
e5eecef
Compare
e5eecef to
625425e
Compare
625425e to
3a1c567
Compare
|
Looks like the PR description needs to be updated since it currently refers to the wrong issue. |
| # XFAIL: Clang && Vulkan | ||
|
|
||
| # Driver Bug: https://gitlab.freedesktop.org/mesa/mesa/-/work_items/16596 | ||
| # XFAIL: Lavapipe && (host-x86 || host-x86_64) && DXC |
There was a problem hiding this comment.
Why && DXC? Presumably once #1435 is completed this would start failing on clang as well?
There was a problem hiding this comment.
Yeah, most likely. I will remove the && DXC here
16f6b1f to
7f04d62
Compare
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 643c3c11-3596-47b0-acc4-1fa90c8e4d85
Annotate 107 tests for Mesa issue 16596: 53 fail with both compilers, 52 only with DXC, and 2 only with Clang. Scope the XFAILs to the requested Lavapipe and AMD features. Remove obsolete issue annotations and inherited no-output access-violation exclusions that are absent from both logs. The AMD feature currently identifies AMD GPU descriptions, not the llvmpipe host runner; these requested conditions require AMD to be supplied separately for that runner. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: ea4455aa-9cd1-48c2-8568-2a6d5786a339
7f04d62 to
556ac4d
Compare
| # XFAIL: Metal | ||
|
|
||
| # Driver Bug: https://gitlab.freedesktop.org/mesa/mesa/-/work_items/16596 | ||
| # XFAIL: Lavapipe && (host-x86 || host-x86_64) && DXC |
There was a problem hiding this comment.
This test is weird; it says clang doesn't implement TextureCubeArray, but it doesn't xfail either. So I think the right approach here would be to XFAIL on clang as well, since it is not implemented. But that change is not in scope with this patch. I am happy to address it in a follow-up PR if reviewers agree with this fix.
Marking test affected by issue https://gitlab.freedesktop.org/mesa/mesa/-/work_items/16596 as XFAIL
Fix: #1527