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

[Edward O'Callaghan]

Hey guys,

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. 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?

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160810/2d2068ff/attachment-0001.sig>