On 22/02/2021 22:43, Dan Horák wrote: > On Mon, 22 Feb 2021 21:19:26 -0000 > "Tom Seewald" <tseewald@xxxxxxxxx> wrote: > >>> On 22/02/2021 21:18, Tom Seewald wrote: >>> >>> >>> >>> Personally, I have an older GPU, RX 580 Polaris series, I will only >>> spend dev time on the AMD Navi GPU issues after AMD makes the RX 6800 XT >>> available in my region. I simply don't have that card and I'm not going >>> to waste money buying the original Navi card, RX 5700, when the new card >>> will arrive imminently. >> >> There is no indication from the bug report that it requires a Navi card to reproduce. The reporter stated that they are using a RX Vega 56 which is the previous gpu generation. Why do you believe this is specific to Navi devices? To clarify, there are a range of different issues with different amdgpu cards If anybody can provide tips for troubleshooting in any of these bug reports it would be very welcome. https://gitlab.freedesktop.org/drm/amd/-/issues/1519 navi2 - RX 6900 XT https://gitlab.freedesktop.org/drm/amd/-/issues/1446 vega RX 56 Red Dragon https://gitlab.freedesktop.org/drm/amd/-/issues/1293 Fiji-based cards since kernel 5.7 >>> Ultimately, even if it isn't hard to bisect, it doesn't feel fair that >>> AMD is validating their drivers work on x86 before a release but the >>> ppc64le users have to check things after a buggy release. >> >> Unfortunately smaller platforms will almost always get less testing than the more popular platforms, and I don't see that trend changing in the foreseeable future. This is where motivated community members need to come in. I doubt amdgpu developers even have easy access to ppc64le hardware. Does anybody know about programs from AMD or any other vendor to make their hardware available to volunteers in the Fedora development world? This is even more critical now that GPU delivery is such a huge problem. Shops that receive stock are selling it at double the RRP. Volunteers won't rush to buy those cards and it will take even longer to fully support them. Simply having a critical mass of developers with the right hardware can make a huge difference. For example, with 7 developers, maybe a given platform is always overloaded but with 8 developers maybe the backlog of bugs is fixed faster than new bugs are discovered. The same phenomena appears in so many domains: what some of us perceive now is like the congestion on a freeway at peak hour when the cars come in faster than they can go out. >> I will also say that regardless of ISA there are going to be times where bisection is needed. I have personally had to bisect and report an issue with amdgpu and I am using x86 hardware. There's also a decent chance I'm going to be bisecting another amdgpu bug this evening. I am not expecting you or others to do things that I am not willing to do myself. >> >>> I'm all in favor of collaboration with the AMD and kernel developers >>> >>> Ultimately, the only way to ensure equality across different >>> architectures is to have upstream developers using all of these >>> architectures throughout their development cycle. >> >> It would of course be great if amd fully tested their drivers on every architecture that Linux supports, but I don't think that's currently a realistic expectation for *any* device/driver vendor. If amdgpu support is something that is important to IBM, Talos, or other members of OpenPower, then I think reaching out to developers and offering free ppc64le hardware or VM access for kernel development and testing would be an excellent start. Providing automated ppc64le build and boot testing for the amd-staging-drm-next tree would be great as well. > > There has been such idea within the OpenPOWER Foundation some time ago, > to have a lab where (primarily) HW vendors would have access and could > test their HW and drivers on a number of different platforms. I suppose > we should revive this idea. > In the SIP world, we had SIPit events for this type of testing from time to time. Having people get together can be fun and productive. Maybe it will be possible in 2022 or beyond. From a Fedora perspective, it could be interesting to align it with the release schedule. https://www.sipforum.org/news-events/test-event-wg-overview-and-charter-sipit/upcoming-sipit-events/ > > Dan > >> >>> How can we encourage greater use of ppc64le and aarch64 in those >>> communities? While it may sound trivial, I made a post here last week >>> about how we can help people choose the right workstation through the wiki: >>> >>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o... >>> >>> I estimate spending one or two hours in my own comparison of the Raptor >>> motherboards and I hope the table allows other developers to save the >>> same amount of time. >> >> While there's no silver bullet, reaching out to the upstream developers (e.g. via their mailing list) and having a conversation with them can't hurt. Understanding their position and what they believe would help with testing is going to be an important part of the solution. >> _______________________________________________ >> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx >> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx >> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx >> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure > _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
