Re: Moving amber into separate repo?
W dniu: Niedziela, Wrzesień 25, 2022 08:16 CEST, "Eric Engestrom"
napisał(a):
Hi Filip!
Others have what explained why copying the repo (and everything around it) is
not a good idea, so I'll only reply to the other points.
On 2022-09-22 at 22:37 UTC+02:00, Filip Gawin 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".
Could you explain *where* you would like to do this? I don't see what *users*
would see where this would help.
> 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 think we should probably add a couple of lines in the meson.build on the
amber branch, like this:
if gallium_drivers.count() != 0 or vulkan_drivers.count() != 0
error("You shouldn't package Gallium or Vulkan drivers from the amber branch;
please only enable these in the standard Mesa package build.")
endif
Do you think that would be enough to resolve the distro packages maintainers'
confusion?
Hi, I think the problem with Amber is that the situation isn't clear. Branch
appeared from nowhere and without clear goal. (Some commits for new drivers
landed on it. So it may be giving wrong idea about LTS.) Moving into separate
repo was my first idea to address this problem, but I agree it may not be best
solution.
Overall I think we have problems:
- branch is difficult to find (adding link in readme of main branch and
renaming branch?)
- sometimes commits for drivers still supported by main branch are modifying
gallium, so there's chance of regression (or accidental use). (we can disable
them, but probably removing is better?)
- people don't correlate amber and legacy. Here's video with with chipset 945g
(915g) and lubuntu. https://youtu.be/nCjantxylV4?t=1160 (btw there's another
problem why 945g only advertise gl 1.4) So adding "Legacy" or "Legacy driver"
after word Mesa my be a good idea.
Re: Moving amber into separate repo?
Hi Filip!
Others have what explained why copying the repo (and everything around it) is
not a good idea, so I'll only reply to the other points.
On 2022-09-22 at 22:37 UTC+02:00, Filip Gawin 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".
Could you explain *where* you would like to do this? I don't see what *users*
would see where this would help.
> 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 think we should probably add a couple of lines in the meson.build on the
amber branch, like this:
if gallium_drivers.count() != 0 or vulkan_drivers.count() != 0
error("You shouldn't package Gallium or Vulkan drivers from the amber branch;
please only enable these in the standard Mesa package build.")
endif
Do you think that would be enough to resolve the distro packages maintainers'
confusion?
Re: Moving amber into separate repo?
Currently, amber branch only have * radeon * r200 * i915 * i965 * nouveau (the DRI driver for NV04-NV20) Indeed, I think i915 and i965 can also be removed from amber branch, because they have alternative i915g/ crocus alternatives in main branch, maybe in future, after all code that's not belongs to amber removed, we can even place amber under main branch's src/amber folder? -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo
Re: Moving amber into separate repo?
On September 24, 2022 04:04:48 "Filip Gawin" wrote: 2. repo is growing large. Amber kinda requires long history, modern mesa not. This may be good spot to split if cleanup is required. mesa absolutely uses long history. there is nothing to clean up. those bytes of disk space are well worth it. (Neutral on the other points, I don't work on stuff suported in Amber) I thought here about traces in issues. (Sometimes traces are uploaded onto gitlab by users.) I'm guessing it should be possible to reedit really old closed issues and remove attachments. If the fd.o admins are complaining about disk usage, we can take steps to reduce that but it's entirely irrelevant to the discussion of whether amber should get it's own repo. Pulling amber into a separate repo won't reduce disk usage. If anything, it'll slightly increase it but not by an amount that's likely to matter. Let's stay focused on actual reasons that might matter, like user confusion (if that's actually happening). --Jason
Re: Moving amber into separate repo?
> 2. repo is growing large. Amber kinda requires long history, modern > mesa not. This may be good spot to split if cleanup is required. mesa absolutely uses long history. there is nothing to clean up. those bytes of disk space are well worth it. (Neutral on the other points, I don't work on stuff suported in Amber)I thought here about traces in issues. (Sometimes traces are uploaded onto gitlab by users.) I'm guessing it should be possible to reedit really old closed issues and remove attachments.
Re: Moving amber into separate repo?
Removing mainline drivers from the build system of Amber is a good idea. Marek On Fri, Sep 23, 2022, 06:33 Filip Gawin 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.
Re: Moving amber into separate repo?
Git stores all commits. Removing files at the top of main doesn't make the repository smaller. It actually makes it bigger. Forking the repository would also double the size on the server. Marek On Fri, Sep 23, 2022, 06:33 Filip Gawin 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.
Re: Moving amber into separate repo?
> 2. repo is growing large. Amber kinda requires long history, modern > mesa not. This may be good spot to split if cleanup is required. mesa absolutely uses long history. there is nothing to clean up. those bytes of disk space are well worth it. (Neutral on the other points, I don't work on stuff suported in Amber)
Re: Moving amber into separate repo?
On Fri, Sep 23, 2022 at 3:33 AM Filip Gawin 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.
Moving amber into separate repo?
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. Thanks for all insights, Filip.
