On Fri, Sep 23, 2022 at 3:33 AM Filip Gawin <fi...@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: > > web based tools provided by gitlab are quite useful, unfortunately they work > best with main branch. > repo is growing large. Amber kinda requires long history, modern mesa not. > This may be good spot to split if cleanup is required. > 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.) > 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. >
not sure we need a different repo, but I would recommend disabling/removing drivers (gallium and vk) in the amber branch which are maintained in the main branch BR, -R > > Thanks for all insights, Filip.
