On Tue, Aug 9, 2016 at 5:35 PM, Nicolai Hähnle <nhaeh...@gmail.com> wrote: > On 09.08.2016 17:21, Marek Olšák wrote: >> >> On Tue, Aug 9, 2016 at 3:47 PM, Nicolai Hähnle <nhaeh...@gmail.com> wrote: >>> >>> Hi everybody, >>> >>> addrlib is the addressing and alignment calculator which is used by >>> radeonsi. It's developed (and also used) internally at AMD, and so far >>> we've >>> had one open source copy living in the Mesa repository at >>> src/gallium/winsys/amdgpu/drm/addrlib. >>> >>> The question of using addrlib in non-Mesa parts of our open-source stack >>> has >>> come up, in particular in relation to compute. We'd obviously like to >>> share >>> the code rather than having multiple copies flying around. Since the >>> interface of addrlib is slow-moving but unstable, shared linking is not >>> an >>> option. >>> >>> I think the best way forward is to create a dedicated repository for >>> addrlib >>> which is then integrated into Mesa as a git submodule. >>> >>> The point of this email is to gather feedback from the Mesa community on >>> this plan, which is explicitly: >>> >>> (0) Create an addrlib repository, say amd/addrlib on fd.o. >>> (1) Add it as a git submodule to the Mesa repository. >>> (2) Fix up whatever aspects of the build system that may be affected >>> (perhaps for building source tarballs). >>> (3) Go back to mostly ignoring addrlib, except for trying to get better >>> at >>> syncing with the internal closed-source version. >>> >>> From initial experiments, the impact on users interested in radeon is >>> that >>> they will have to run `git submodule init` and then occasionally `git >>> submodule update`. Users who do not build radeonsi should be able to >>> ignore >>> the change completely. >>> >>> There are alternatives. For example, ROCm uses Google's repo tool >>> already. >>> But for Mesa, git submodule looks like a lightweight, well supported and >>> overall conservative option that everybody should already have installed. >>> If >>> there are good arguments for something else, let's hear them! >>> >>> Another point: if we proceed with this plan, I think we should consider >>> moving addrlib into src/amd/addrlib. There are two reasons: First, >>> transitioning to a submodule *without* changing the directory is probably >>> more fragile, i.e. what happens when you switch between checkouts before >>> and >>> after the transition. Second, if/when radv ends up being merged into Mesa >>> master, it makes sense to have addrlib there anyway. >>> >>> Thoughts? Complaints? Praise? >> >> >> I don't know. >> >> How does this ensure that Mesa and ROCm addrlib copies won't diverge? > > > They won't really be different copies, because both "copies" are really > checkouts from the same repository. They will occasionally be checkouts of > _different versions_ from the same repository -- usually that would happen > after a sync with the internal copy, when one driver updates their pointer > before the other does. But that's easiy to reconcile. Usually it should just > mean changing the version pointer in whichever driver uses the older > version. > > >> What issues can we expect if Mesa and ROCm addrlib copies diverge? > > > This is about software maintenance. If we _do_ have separate copies, and > someone applies a bug fix in one copy, they may forget to apply it to the > other. When we want to sync with the internal copy, that has to be done > twice. Basically, all the usual frictions that go with having the same (or > almost the same) piece of code in more than one place.
Instead of introducing a new repo, can ROCm simply copy addrlib directly from the Mesa tree? If I understand it correctly, the only thing the git submodule would allow is that ROCm developers wouldn't have to clone Mesa. Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
