[Mesa-dev] Moving amdgpu/addrlib into a git submodule

[Nicolai Hähnle]

On 10.08.2016 06:22, Edward O'Callaghan wrote:
> Well taking a step back here for a second. My initial thoughts are -
> what, conceptually, is the primary user of addrlib from an extremely
> high level view?
>
> If the case is mesa3d then perhaps mesa should be treated as the
> upstream from which other users pull.

Mesa really doesn't make logical sense as a dependency for the HSA stack.


> If the case is that it is indeed
> truly agnostic/general then perhaps deferring to the packaging
> expertise/infrastructure of the distro's (aka pkgconfig, etc..) is
> perhaps the best mechanism.  In the latter case, addrlib would be
> released with versioning which should be fairly maintainable as it is a
> slowly moving target right?

Please no. Those things are a fragile mess. I appreciate it the thought, 
but there's a reason why major version upgrades of shared libraries are 
feared.

Nicolai



>
> Just my two cent, hope its helpful!
> Kind Regards,
> Edward.
>
> On 08/10/2016 01:39 AM, Christian König wrote:
>> Am 09.08.2016 um 15:47 schrieb Nicolai Hähnle:
>>> 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?
>>
>> Well using git submodule is a possibility and we had rather good
>> experience with that in GStreamer.
>>
>> But it would remove one major argument to beating the addrlib guys
>> towards a stable interface and/or proper library version handling.
>>
>> Moving it into libdrm is clearly not an option because then you would
>> need to use versioning for the whole libdrm_amdgpu library which we
>> don't want.
>>
>> Christian.
>>
>>> Nicolai
>>> _______________________________________________
>>> mesa-dev mailing list
>>> mesa-dev at lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>>
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>