Re: [git pull] drm CI integration
On Sun, 10 Sept 2023 at 21:05, Linus Torvalds wrote: > > On Wed, 30 Aug 2023 at 18:00, Dave Airlie wrote: > > > > This is a PR to add drm-ci support files to the upstream tree. > > So I finally had no other pull requests pending, and spent some time > looking at this, and I see nothing offensive. > > I did wonder how this then expands to having more than one subsystem > using this (and mixing them possibly on the same CI system), but > that's more about my ignorance about how the gitlab CI works than > anything else, so that's certainly not a real concern. I forgot to put this into my write up, but one reason I think gitlab CI is a notch better than all the others is that it at least tries to have an answer here: - each gitlab repo has its own configuration for where to find the CI files (also out-of-tree if you go really wild for hw testing maybe) - you can include gitlab CI files Which together means you can share common stuff like compile testing or qemu based testing while easily having specific jobs per driver/subsystem/whatever that do hw testing. So if media also gains fd.o gitlab support the media stuff could be in drivers/media/ci (and at that point we probably want scripts/ci for common stuff). > The other side of that "I do wonder" coin is for when others want to > use the same tests but using some other CI infrastructure, whether > it's some AWS or google cloud thing, or github or whatever. gitlab has a standalone runner, so at least for the sw-only stuff if you have some other Ci (like distros that want to test everything) they should be able to reuse the fd.o specific stuff fairly verbatim, or at least with some minimal adjustements in upstream. So building a CI-of-CIs should be doable. Worst case one level below reusing the docker images should be doable in practically anything that can run a vm. > Anyway, considering that both of my idle curiosity reactions were > about "if this is successful", I think me having those questions only > means that I should pull this, rather than questioning the pull > itself. > > If it works out so well that others want to actually do this and > integrate our other selftests in similar manners, I think that would > be lovely. > > And if - as you say - this is a failure and the whole thing gets > deleted a year from now as "this didn't go anywhere", it doesn't look > like it should cause a ton of problems either. > > Anyway, it's in my tree now, let's see where it goes. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [git pull] drm CI integration
The pull request you sent on Thu, 31 Aug 2023 11:00:20 +1000: > git://anongit.freedesktop.org/drm/drm tags/topic/drm-ci-2023-08-31-1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/1548b060d6f32a00a2f7e2c11328205fb66fc4fa Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [git pull] drm CI integration
On Wed, 30 Aug 2023 at 18:00, Dave Airlie wrote: > > This is a PR to add drm-ci support files to the upstream tree. So I finally had no other pull requests pending, and spent some time looking at this, and I see nothing offensive. I did wonder how this then expands to having more than one subsystem using this (and mixing them possibly on the same CI system), but that's more about my ignorance about how the gitlab CI works than anything else, so that's certainly not a real concern. The other side of that "I do wonder" coin is for when others want to use the same tests but using some other CI infrastructure, whether it's some AWS or google cloud thing, or github or whatever. Anyway, considering that both of my idle curiosity reactions were about "if this is successful", I think me having those questions only means that I should pull this, rather than questioning the pull itself. If it works out so well that others want to actually do this and integrate our other selftests in similar manners, I think that would be lovely. And if - as you say - this is a failure and the whole thing gets deleted a year from now as "this didn't go anywhere", it doesn't look like it should cause a ton of problems either. Anyway, it's in my tree now, let's see where it goes. Linus
Re: [git pull] drm CI integration
On Thu, 31 Aug 2023 at 03:00, Dave Airlie wrote: > > Hey Linus, > > This is a PR to add drm-ci support files to the upstream tree. > This is a bunch of ci integration for the freedesktop gitlab instance > where we currently do upstream userspace testing on diverse sets of GPU > hardware. From my perspective I think it's an experiment worth going with > and seeing how the benefits/noise playout keeping these files useful. > > Ideally I'd like to get this so we can do pre-merge testing on PRs eventually. > > Below is some info from danvet on why we've ended up making the > decision and how we can roll it back if we decide it was a bad plan. > > Why in upstream? > > - like documentation, testcases, tools CI integration is one of these things > where you can waste endless amounts of time if you accidentally have a > version > that doesn't match your source code > > - but also like the above, there's a balance, this is the initial cut of what > we > think makes sense to keep in sync vs out-of-tree, probably needs adjustment > > - gitlab supports out-of-repo gitlab integration and that's what's been used > for > the kernel in drm, but it results in per-driver fragmentation and lots of > duplicated effort. the simple act of smashing an arbitrary winner into a > topic > branch already started surfacing patches on dri-devel and sparking good > cross driver team discussions > > Why gitlab? > > - it's not any more shit than any of the other CI > > - drm userspace uses it extensively for everything in userspace, we have a lot > of people and experience with this, including integration of hw testing labs > > - media userspace like gstreamer is also on gitlab.fd.o, and there's > discussion > to extend this to the media subsystem in some fashion > > Can this be shared? > > - there's definitely a pile of code that could move to scripts/ if other > subsystem adopt ci integration in upstream kernel git. other bits are more > drm/gpu specific like the igt-gpu-tests/tools integration > > - docker images can be run locally or in other CI runners > > Will we regret this? > > - it's all in one directory, intentionally, for easy deletion > > - probably 1-2 years in upstream to see whether this is worth it or a Big > Mistake. that's roughly what it took to _really_ roll out solid CI in the > bigger userspace projects we have on gitlab.fd.o like mesa3d Maybe a bit more on what scenarios I see over the next 1-2 year for this. 0. Utter Failure: Currently we have the bad combo of shit drivers/shit igt tests/shit ci, and the eye-gauging PR here is really just surfacing this mess and bringing it into the spotlight. if things don't improve at all, and we're still at the same point in 2 year as we are now, this was a failure and drm/ci needs to be unceremonuously deleted. I might head out and pick up goat farming in the alps in this case :-/ 1. Better build testing: - we manage to solidly integrate this into our PR and committer flows, currently that's not really the case because of a bit a chicken/egg situation. this is a ton of work, but 1-2 years should be enough for results - better build time testing hopefully encourages people to build more kunit and other build time tests, especially for the more complex libraries we have that are really hard to exhaustively test with real hw, like the dp mst library - in that case we'd keep drm/ci, but probably throw out the hw driver testing integration and push that down into the per-driver separate git repos. gitlab can cope with this and even in the driver repos with the out-of-tree hw testing ci integration still include the build-time testing targets from upstream and run them, so we'd still get much better collaboration across drivers on the build testing - this is kinda the "no more shit ci" achievement 2. Better igts for virtual drivers: - better build testing, plus: - media I think is really great here with having fully virtual driverrs to validate any new interfaces and testcases against. we're trying to build the same up with vgem/vkms since a few years, but it's slow going. vgem/vkms integration isn't in this PR, but it's already in the works, and I'm hoping that we can at least fix the igt test quality mess a bit by getting to the point where igt tests for new kms uapi must pass on vkms. - in this case we might keep some of the hw driver testing integration simply as a canary in the coal mine, but until we have some solid drivers beyond vkms we'd have to limit that severely to not cause too much eye gauging in that directory - this would get us to the "no more shit igt tests" achievement 3. "We can dream": - we also manage to fix up the shit driver sitatution for at least some drivers, and can have a fairly broad selection of hw driver testing in ci. Given how much intel gfx ci is struggling with this, and for years, this might only be realistic for fairly small drivers and in really well controlled settings - realistically there's no
[git pull] drm CI integration
Hey Linus, This is a PR to add drm-ci support files to the upstream tree. This is a bunch of ci integration for the freedesktop gitlab instance where we currently do upstream userspace testing on diverse sets of GPU hardware. From my perspective I think it's an experiment worth going with and seeing how the benefits/noise playout keeping these files useful. Ideally I'd like to get this so we can do pre-merge testing on PRs eventually. Below is some info from danvet on why we've ended up making the decision and how we can roll it back if we decide it was a bad plan. Why in upstream? - like documentation, testcases, tools CI integration is one of these things where you can waste endless amounts of time if you accidentally have a version that doesn't match your source code - but also like the above, there's a balance, this is the initial cut of what we think makes sense to keep in sync vs out-of-tree, probably needs adjustment - gitlab supports out-of-repo gitlab integration and that's what's been used for the kernel in drm, but it results in per-driver fragmentation and lots of duplicated effort. the simple act of smashing an arbitrary winner into a topic branch already started surfacing patches on dri-devel and sparking good cross driver team discussions Why gitlab? - it's not any more shit than any of the other CI - drm userspace uses it extensively for everything in userspace, we have a lot of people and experience with this, including integration of hw testing labs - media userspace like gstreamer is also on gitlab.fd.o, and there's discussion to extend this to the media subsystem in some fashion Can this be shared? - there's definitely a pile of code that could move to scripts/ if other subsystem adopt ci integration in upstream kernel git. other bits are more drm/gpu specific like the igt-gpu-tests/tools integration - docker images can be run locally or in other CI runners Will we regret this? - it's all in one directory, intentionally, for easy deletion - probably 1-2 years in upstream to see whether this is worth it or a Big Mistake. that's roughly what it took to _really_ roll out solid CI in the bigger userspace projects we have on gitlab.fd.o like mesa3d Dave + Daniel. topic/drm-ci-2023-08-31-1: drm ci for 6.6-rc1 Add CI integration support files for drm subsystem to gitlab.freedesktop.org instance. The following changes since commit 3698a75f5a98d0a6599e2878ab25d30a82dd836a: Merge tag 'drm-intel-next-fixes-2023-08-24' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2023-08-25 12:55:55 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/topic/drm-ci-2023-08-31-1 for you to fetch changes up to ad6bfe1b66a5c146ec236847eca7af4c8806d666: drm: ci: docs: fix build warning - add missing escape (2023-08-29 19:56:11 +0200) drm ci for 6.6-rc1 Add CI integration support files for drm subsystem to gitlab.freedesktop.org instance. Helen Koike (1): drm: ci: docs: fix build warning - add missing escape Tomeu Vizoso (1): drm: Add initial ci/ subdirectory Documentation/gpu/automated_testing.rst| 144 + Documentation/gpu/index.rst|1 + MAINTAINERS|8 + drivers/gpu/drm/ci/arm.config | 69 + drivers/gpu/drm/ci/arm64.config| 199 ++ drivers/gpu/drm/ci/build-igt.sh| 35 + drivers/gpu/drm/ci/build.sh| 157 ++ drivers/gpu/drm/ci/build.yml | 110 + drivers/gpu/drm/ci/check-patch.py | 57 + drivers/gpu/drm/ci/container.yml | 65 + drivers/gpu/drm/ci/gitlab-ci.yml | 251 ++ drivers/gpu/drm/ci/igt_runner.sh | 77 + drivers/gpu/drm/ci/image-tags.yml | 15 + drivers/gpu/drm/ci/lava-submit.sh | 57 + drivers/gpu/drm/ci/static-checks.yml | 12 + drivers/gpu/drm/ci/test.yml| 335 +++ drivers/gpu/drm/ci/testlist.txt| 2912 drivers/gpu/drm/ci/x86_64.config | 111 + drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt | 19 + drivers/gpu/drm/ci/xfails/amdgpu-stoney-flakes.txt | 21 + drivers/gpu/drm/ci/xfails/amdgpu-stoney-skips.txt |2 + drivers/gpu/drm/ci/xfails/i915-amly-fails.txt | 17 + drivers/gpu/drm/ci/xfails/i915-amly-flakes.txt | 32 + drivers/gpu/drm/ci/xfails/i915-amly-skips.txt |4 + drivers/gpu/drm/ci/xfails/i915-apl-fails.txt | 58 + drivers/gpu/drm/ci/xfails/i915-apl-flakes.txt |1 + drivers/gpu/drm/ci/xfails/i915-apl-skips.txt |6 + drivers/gpu/drm/ci/xfails/i915-cml-fails.txt | 18 + drivers/g
