Moving amber into separate repo?

[Marek Olšák]

Removing mainline drivers from the build system of Amber is a good idea.

Marek

On Fri, Sep 23, 2022, 06:33 Filip Gawin <filip at gawin.net> wrote:

> Hi, recently I've seen case of user been using Amber when hardware was
> supported by mainline mesa. This gave me a couple of thoughts.
>
> 1) Users don't correlate "Amber" with "Legacy" and probably it's gonna be
> best to always also print "Legacy" together with "Mesa".
> 2) Not sure if problem of choosing best driver is on mesa's or distro
> maintainer's side, but it became more complicated for maintainers.
>
> I'm thinking that moving Amber into separate repo may make this situation
> more clear. (Disabling duplicated drivers or only allowing glsl_to_tgsi
> codepath may futher help.)
>
> Some more reasoning from gitlab:
>
>
>    1. web based tools provided by gitlab are quite useful, unfortunately
>    they work best with main branch.
>    2. repo is growing large. Amber kinda requires long history, modern
>    mesa not. This may be good spot to split if cleanup is required.
>    3. imho having amber's issues in this repo, won't create new
>    contributors. Due to lack of kernel driver (on commercial level) or
>    documentation for these gpus, so you need to be both mesa and kernel
>    developer. (Any contribution is gonna require deep knowledge about
>    hardware, domain and time consuming effort.)
>    4. for normal users (not software developers) amber is kinda "hidden
>    under the carpet". Communities like vogons may be interested in having
>    simpler access to kinda documentation for these ancient gpus.
>
>
> Thanks for all insights, Filip.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20220924/ec377ddb/attachment.htm>