info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#857172: Please enable SSE2 on amd64 and disable altivec on PPC ports
6 views
Skip to first unread message
Laurent Bigonville
Mar 8, 2017, 10:10:02 AM3/8/17
to
Source: babl
Version: 0.1.18-1
Severity: normal
Hi,
According to [0], optimisation upto SSE2 can be enabled on amd64.
Also, I'm not sure that altivec is officially supported on any of the
ppc ports, so I'm disabling it completely, I'm putting debian-powerpc ML
in copy.
See attached patch.
Regards,
Laurent Bigonvilleo
[0] https://www.debian.org/ports/amd64/index.en.html
-- System Information:
Debian Release: 9.0
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Version: 0.1.18-1
Severity: normal
Hi,
According to [0], optimisation upto SSE2 can be enabled on amd64.
Also, I'm not sure that altivec is officially supported on any of the
ppc ports, so I'm disabling it completely, I'm putting debian-powerpc ML
in copy.
See attached patch.
Regards,
Laurent Bigonvilleo
[0] https://www.debian.org/ports/amd64/index.en.html
-- System Information:
Debian Release: 9.0
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
John Paul Adrian Glaubitz
Mar 8, 2017, 10:10:02 AM3/8/17
to
On Wed, Mar 08, 2017 at 03:57:55PM +0100, Laurent Bigonville wrote:
> Also, I'm not sure that altivec is officially supported on any of the
> ppc ports, so I'm disabling it completely, I'm putting debian-powerpc ML
> in copy.
The firefox package is built with AltiVec enabled and so is mplayer,
> Also, I'm not sure that altivec is officially supported on any of the
> ppc ports, so I'm disabling it completely, I'm putting debian-powerpc ML
> in copy.
for example. So, yes, Altivec is actively used and I would honestly
refrain from disabling it in a performance-sensitive package like
babl.
Altivec is disabled on powerpcspe where it's not available in the
hardware, but most machines on which people install Debian powerpc
should have Altivec.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glau...@debian.org
`. `' Freie Universitaet Berlin - glau...@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Laurent Bigonville
Mar 8, 2017, 10:40:03 AM3/8/17
to
Le 08/03/17 à 16:06, John Paul Adrian Glaubitz a écrit :
should be disabled as they are not supporting it IIRC (longtime I didn't
use a ppc machine).
If you are telling me altivec is OK, I guess that the flag can be
removed and the situation can be kept as before for PPC
> On Wed, Mar 08, 2017 at 03:57:55PM +0100, Laurent Bigonville wrote:
>> Also, I'm not sure that altivec is officially supported on any of the
>> ppc ports, so I'm disabling it completely, I'm putting debian-powerpc ML
>> in copy.
> The firefox package is built with AltiVec enabled and so is mplayer,
> for example. So, yes, Altivec is actively used and I would honestly
> refrain from disabling it in a performance-sensitive package like
> babl.
>
> Altivec is disabled on powerpcspe where it's not available in the
> hardware, but most machines on which people install Debian powerpc
> should have Altivec.
For the powerpc port, if G3 are still supposed to be supported, altivec
>> Also, I'm not sure that altivec is officially supported on any of the
>> ppc ports, so I'm disabling it completely, I'm putting debian-powerpc ML
>> in copy.
> The firefox package is built with AltiVec enabled and so is mplayer,
> for example. So, yes, Altivec is actively used and I would honestly
> refrain from disabling it in a performance-sensitive package like
> babl.
>
> Altivec is disabled on powerpcspe where it's not available in the
> hardware, but most machines on which people install Debian powerpc
> should have Altivec.
should be disabled as they are not supporting it IIRC (longtime I didn't
use a ppc machine).
If you are telling me altivec is OK, I guess that the flag can be
removed and the situation can be kept as before for PPC
Lennart Sorensen
Mar 8, 2017, 11:00:02 AM3/8/17
to
On Wed, Mar 08, 2017 at 04:06:17PM +0100, John Paul Adrian Glaubitz wrote:
> The firefox package is built with AltiVec enabled and so is mplayer,
> for example. So, yes, Altivec is actively used and I would honestly
> refrain from disabling it in a performance-sensitive package like
> babl.
>
> Altivec is disabled on powerpcspe where it's not available in the
> hardware, but most machines on which people install Debian powerpc
> should have Altivec.
e5500 does not have it, which means one of the modern powerpc chips
> The firefox package is built with AltiVec enabled and so is mplayer,
> for example. So, yes, Altivec is actively used and I would honestly
> refrain from disabling it in a performance-sensitive package like
> babl.
>
> Altivec is disabled on powerpcspe where it's not available in the
> hardware, but most machines on which people install Debian powerpc
> should have Altivec.
doesn't support it.
Certainly the powerpc64 port claims e5500 support, and hence does NOT
assume altivec support.
It really is something that should be runtime detected and used if
present but not required.
--
Len Sorensen
John Paul Adrian Glaubitz
Mar 8, 2017, 11:00:03 AM3/8/17
to
On Wed, Mar 08, 2017 at 10:52:21AM -0500, Lennart Sorensen wrote:
> e5500 does not have it, which means one of the modern powerpc chips
> doesn't support it.
>
> Certainly the powerpc64 port claims e5500 support, and hence does NOT
> assume altivec support.
Right. But that was something that was just changed recently. Because
> e5500 does not have it, which means one of the modern powerpc chips
> doesn't support it.
>
> Certainly the powerpc64 port claims e5500 support, and hence does NOT
> assume altivec support.
one e5500 user complained about it.
> It really is something that should be runtime detected and used if
> present but not required.
complained so far unlike with the ppc64 port. So I really think it
should stay that way. Most PowerPC machines are already underpowered,
so taking away Altivec on applications where it really makes a
difference would be suboptimal.
John Paul Adrian Glaubitz
Mar 8, 2017, 11:00:04 AM3/8/17
to
On Wed, Mar 08, 2017 at 04:28:52PM +0100, Laurent Bigonville wrote:
> For the powerpc port, if G3 are still supposed to be supported, altivec
> should be disabled as they are not supporting it IIRC (longtime I didn't use
> a ppc machine).
Would it make much sense to run something like GIMP on a G3? I'd
> For the powerpc port, if G3 are still supposed to be supported, altivec
> should be disabled as they are not supporting it IIRC (longtime I didn't use
> a ppc machine).
expect the performance to be rather underwhelming. Same applies to
mplayer and Firefox.
Even a G4 is rather underpowered for something like GIMP. But at
least, it would take advantage from Altivec.
> If you are telling me altivec is OK, I guess that the flag can be removed
> and the situation can be kept as before for PPC
complains :). So, please let's just keep it the way it is.
Riccardo Mottola
Mar 8, 2017, 11:20:02 AM3/8/17
to
Hi,
are many CPUs without altivec (including PPC601/601/604)
Some applications enable alitvec only on runtime - but if that doesn't
work, big trouble (e.g. what happened with jpeg turbo).
Riccardo
Laurent Bigonville wrote:
> For the powerpc port, if G3 are still supposed to be supported,
> altivec should be disabled as they are not supporting it IIRC
> (longtime I didn't use a ppc machine).
>
> If you are telling me altivec is OK, I guess that the flag can be
> removed and the situation can be kept as before for PPC
I do happily run on my iBook... including firefox, which is G3. There
> For the powerpc port, if G3 are still supposed to be supported,
> altivec should be disabled as they are not supporting it IIRC
> (longtime I didn't use a ppc machine).
>
> If you are telling me altivec is OK, I guess that the flag can be
> removed and the situation can be kept as before for PPC
are many CPUs without altivec (including PPC601/601/604)
Some applications enable alitvec only on runtime - but if that doesn't
work, big trouble (e.g. what happened with jpeg turbo).
Riccardo
Konstantinos Margaritis
Mar 8, 2017, 11:30:03 AM3/8/17
to
Στις 08-03-2017, ημέρα Τετ, και ώρα 16:55 +0100, ο/η John Paul Adrian
Glaubitz έγραψε:
(powerpc & ppc64). AFAIR, the consensus is that Altivec should be
disabled by default and either enabled in a separate package (eg.
atlas-altivec) or used through runtime detection (eg. ffmpeg, vlc).
If a package does enable altivec by default, then that's a bug and a
policy violation. On the other hand, being a SIMD fanatic that I am, I
wholeheartidly agree on enabling Altivec -and SIMD support in general-
on a distribution-wide scale. If a CPU does not support SIMD (Altivec,
NEON, SSE/AVX, etc), then tough luck (applies to Marvell, e5500, old
Intel/AMD CPUs, etc). But until that happens, we have to support the
decision, if Firefox is built with altivec enabled (and I don't mean
runtime detection, but failure to run on non-altivec CPUs), then that's
a bug, period.
Regards
Konstantinos
Glaubitz έγραψε:
> It should. But it has been like that for ages and no one has
> complained so far unlike with the ppc64 port. So I really think it
> should stay that way. Most PowerPC machines are already underpowered,
> so taking away Altivec on applications where it really makes a
> difference would be suboptimal.
For many years, Altivec enablement has been debated in both ports
> complained so far unlike with the ppc64 port. So I really think it
> should stay that way. Most PowerPC machines are already underpowered,
> so taking away Altivec on applications where it really makes a
> difference would be suboptimal.
(powerpc & ppc64). AFAIR, the consensus is that Altivec should be
disabled by default and either enabled in a separate package (eg.
atlas-altivec) or used through runtime detection (eg. ffmpeg, vlc).
If a package does enable altivec by default, then that's a bug and a
policy violation. On the other hand, being a SIMD fanatic that I am, I
wholeheartidly agree on enabling Altivec -and SIMD support in general-
on a distribution-wide scale. If a CPU does not support SIMD (Altivec,
NEON, SSE/AVX, etc), then tough luck (applies to Marvell, e5500, old
Intel/AMD CPUs, etc). But until that happens, we have to support the
decision, if Firefox is built with altivec enabled (and I don't mean
runtime detection, but failure to run on non-altivec CPUs), then that's
a bug, period.
Regards
Konstantinos
John Paul Adrian Glaubitz
Mar 8, 2017, 11:40:03 AM3/8/17
to
On Wed, Mar 08, 2017 at 06:23:26PM +0200, Konstantinos Margaritis wrote:
> For many years, Altivec enablement has been debated in both ports
> (powerpc & ppc64). AFAIR, the consensus is that Altivec should be
> disabled by default and either enabled in a separate package (eg.
> atlas-altivec) or used through runtime detection (eg. ffmpeg, vlc).
I'm not aware of any of such -altivec packages and stuff like atlas
> For many years, Altivec enablement has been debated in both ports
> (powerpc & ppc64). AFAIR, the consensus is that Altivec should be
> disabled by default and either enabled in a separate package (eg.
> atlas-altivec) or used through runtime detection (eg. ffmpeg, vlc).
should be compiled from source on the target machine anyway for
performance reasons.
I did a quick search and I could only find ardour-altivec. Any others?
> If a package does enable altivec by default, then that's a bug and a
> decision, if Firefox is built with altivec enabled (and I don't mean
> runtime detection, but failure to run on non-altivec CPUs), then that's
> a bug, period.
You shouldn't make such statement without actually mentioning the
> runtime detection, but failure to run on non-altivec CPUs), then that's
> a bug, period.
section of the Debian Policy which states that Altivec has to be
turned off by default or which makes a generic statement regarding
this.
Also, powerpc is not a release architecture anymore, so I don't even
know how relevant such statements from the Debian Policy would be
nowadays.
Thanks,
Konstantinos Margaritis
Mar 8, 2017, 1:50:03 PM3/8/17
to
Στις 08-03-2017, ημέρα Τετ, και ώρα 17:34 +0100, ο/η John Paul Adrian
Glaubitz έγραψε:
packaging them in the first place? Sorry, that's not a very good
argument.
> I did a quick search and I could only find ardour-altivec. Any
> others?
Interesting, atlas-altivec is not released anymore, well, either it's
not supported for powerpc or they do runtime detection. Regardless, we
used to have more -altivec tagged packages, so either we have better
runtime detection or we're running seriously underperforming packages.
> You shouldn't make such statement without actually mentioning the
> section of the Debian Policy which states that Altivec has to be
> turned off by default or which makes a generic statement regarding
> this.
I did not mean to sound offensive, but it's just a fact. If a package
is built with altivec, it will fail on all non-altivec CPUs, so that by
definition makes the package unusable, hence a grave bug report. By all
means, let's change the minimum architecture requirements so that it's
not, and we set Altivec as mandatory but until we do that (and I
actually would vote for that with both hands), it is a grave bug. No
need to even quote policy for that, as right now powerpc port page
states those machines as supported.
> Also, powerpc is not a release architecture anymore, so I don't even
> know how relevant such statements from the Debian Policy would be
> nowadays.
Again I don't disagree there, but since it's not a release
architecture, we could just move on to newer CPUs and change the
minimum specs -which would IMHO be a good thing, as it would lower the
number of supported platforms to a much smaller and more manageable
set. I have enough PowerPC boxes here, but none without Altivec, so
even if I wanted to, I couldn't even test lack of the feature, and I
don't care enough to go into the trouble of doing that.
Regards
Konstantinos
Glaubitz έγραψε:
> I'm not aware of any of such -altivec packages and stuff like atlas
> should be compiled from source on the target machine anyway for
> performance reasons.
That could be applied to many/most/all? packages, so why bother
> should be compiled from source on the target machine anyway for
> performance reasons.
packaging them in the first place? Sorry, that's not a very good
argument.
> I did a quick search and I could only find ardour-altivec. Any
> others?
not supported for powerpc or they do runtime detection. Regardless, we
used to have more -altivec tagged packages, so either we have better
runtime detection or we're running seriously underperforming packages.
> You shouldn't make such statement without actually mentioning the
> section of the Debian Policy which states that Altivec has to be
> turned off by default or which makes a generic statement regarding
> this.
is built with altivec, it will fail on all non-altivec CPUs, so that by
definition makes the package unusable, hence a grave bug report. By all
means, let's change the minimum architecture requirements so that it's
not, and we set Altivec as mandatory but until we do that (and I
actually would vote for that with both hands), it is a grave bug. No
need to even quote policy for that, as right now powerpc port page
states those machines as supported.
> Also, powerpc is not a release architecture anymore, so I don't even
> know how relevant such statements from the Debian Policy would be
> nowadays.
architecture, we could just move on to newer CPUs and change the
minimum specs -which would IMHO be a good thing, as it would lower the
number of supported platforms to a much smaller and more manageable
set. I have enough PowerPC boxes here, but none without Altivec, so
even if I wanted to, I couldn't even test lack of the feature, and I
don't care enough to go into the trouble of doing that.
Regards
Konstantinos
John Paul Adrian Glaubitz
Mar 8, 2017, 2:00:02 PM3/8/17
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 03/08/2017 07:40 PM, Konstantinos Margaritis wrote:
> That could be applied to many/most/all? packages, so why bother packaging them in the first place? Sorry, that's not a very good argument.
Actually, it is. ATLAS is one of these libraries which contain lots
of CPU optimization code and if you really want to use ATLAS for
actual number crunching, you want to build it from source. It is
very common practice in the scientific work. I am a graduated physicist
who used to do number crunching on such clusters and I also happened
to maintain several of such clusters for work.
>> You shouldn't make such statement without actually mentioning the section of the Debian Policy which states that Altivec has to be turned off by default
>> or which makes a generic statement regarding this.
>
> I did not mean to sound offensive, but it's just a fact. If a package is built with altivec, it will fail on all non-altivec CPUs, so that by definition
> makes the package unusable, hence a grave bug report. By all means, let's change the minimum architecture requirements so that it's not, and we set Altivec
> as mandatory but until we do that (and I actually would vote for that with both hands), it is a grave bug. No need to even quote policy for that, as right
> now powerpc port page states those machines as supported.
I am still waiting for the section from the policy. You cannot make these
bold statements and then not come up with the necessary prove.
I assume you are aware of the fact that Debian's i386 port requires at
least an i686 CPU these days. How does that fit with your line of
arguments? According to your logic, all packages would be affected
by RC bugs because they stopped supporting i386 long time ago.
I'm sorry, but this argument contradicts the current practice.
> Again I don't disagree there, but since it's not a release architecture, we could just move on to newer CPUs and change the minimum specs -which would IMHO
> be a good thing, as it would lower the number of supported platforms to a much smaller and more manageable set.
Again, look at i386.
> I have enough PowerPC boxes here, but none without Altivec, so even if I wanted to, I couldn't even test lack of the feature, and I don't care enough to go
> into the trouble of doing that.
So, you actually don't bother at all and don't want to go through
any efforts of testing, yet you insist on your stance. Odd.
Adrian
- --
iQIzBAEBCAAdFiEEYv+KdYTgKVaVRgAGdCY7N/W1+RMFAljAUzYACgkQdCY7N/W1
+RN0GhAAru7u+dxfCqoBqMq2WCDARsM0fSjmAinHlv1IQaPUHmThJ3K1f/P6KgUY
izpG71MMZviyoX4srOuNFo/RbzhtSl58cfhSatYjXM220IV2fHgMcfH+nnkMubnJ
Hc0KEwd6NI8Dh2xO/DEi3YaKPJp3i7hyS9n5RkwXCM0DL4sYG47iou79YSNDwF/+
PkqeeXUUmK9+A7Ste9ON+yVxTidmXunSvJ2ECpigHbjJUw0WjTRK8U6W682e2K2h
TGM6KVi6W8P246wyipeggV3bjhikM3gLITLmcpjgaorhE0WORtzj1acOByPT08e0
w2ixMUjwsZd/QlS/PZaI20jZhO8lDobhteDsnhYgv6ItVmju3Dy7vHeX96eH9hDV
qJOWWLmvNTVnwy0gqVsuAl7JaD1zaCVhmdxHkwyD+qQ0jtsc2Ui83ArrgGPrMmXx
zslVvnYexSbM/nMM33fND9hp7gVsYooWM4yUqGsd7N+oc9V6e9q4l2PfG8QMhDq2
tUNhMo5JDIZUMSYeF4yL7TQuOqqZKMYSEKP7YWIflDct9bMK+n5YTqGV5dowLFhm
14YJ6F7PDJLUbMJKLgZ5zFNE9GnR9kQGiOUpPdhcswVKlU4prOMfHf6OWE1t1O2v
hENYCF67ipIbjMmYJFFECz24HTMAaDA5b0Wcco9nH85ZcBPU5mA=
=kyio
-----END PGP SIGNATURE-----
Hash: SHA256
On 03/08/2017 07:40 PM, Konstantinos Margaritis wrote:
> That could be applied to many/most/all? packages, so why bother packaging them in the first place? Sorry, that's not a very good argument.
of CPU optimization code and if you really want to use ATLAS for
actual number crunching, you want to build it from source. It is
very common practice in the scientific work. I am a graduated physicist
who used to do number crunching on such clusters and I also happened
to maintain several of such clusters for work.
>> You shouldn't make such statement without actually mentioning the section of the Debian Policy which states that Altivec has to be turned off by default
>> or which makes a generic statement regarding this.
>
> I did not mean to sound offensive, but it's just a fact. If a package is built with altivec, it will fail on all non-altivec CPUs, so that by definition
> makes the package unusable, hence a grave bug report. By all means, let's change the minimum architecture requirements so that it's not, and we set Altivec
> as mandatory but until we do that (and I actually would vote for that with both hands), it is a grave bug. No need to even quote policy for that, as right
> now powerpc port page states those machines as supported.
bold statements and then not come up with the necessary prove.
I assume you are aware of the fact that Debian's i386 port requires at
least an i686 CPU these days. How does that fit with your line of
arguments? According to your logic, all packages would be affected
by RC bugs because they stopped supporting i386 long time ago.
I'm sorry, but this argument contradicts the current practice.
> Again I don't disagree there, but since it's not a release architecture, we could just move on to newer CPUs and change the minimum specs -which would IMHO
> be a good thing, as it would lower the number of supported platforms to a much smaller and more manageable set.
> I have enough PowerPC boxes here, but none without Altivec, so even if I wanted to, I couldn't even test lack of the feature, and I don't care enough to go
> into the trouble of doing that.
any efforts of testing, yet you insist on your stance. Odd.
Adrian
- --
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glau...@debian.org
`. `' Freie Universitaet Berlin - glau...@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
-----BEGIN PGP SIGNATURE-----
: :' : Debian Developer - glau...@debian.org
`. `' Freie Universitaet Berlin - glau...@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
iQIzBAEBCAAdFiEEYv+KdYTgKVaVRgAGdCY7N/W1+RMFAljAUzYACgkQdCY7N/W1
+RN0GhAAru7u+dxfCqoBqMq2WCDARsM0fSjmAinHlv1IQaPUHmThJ3K1f/P6KgUY
izpG71MMZviyoX4srOuNFo/RbzhtSl58cfhSatYjXM220IV2fHgMcfH+nnkMubnJ
Hc0KEwd6NI8Dh2xO/DEi3YaKPJp3i7hyS9n5RkwXCM0DL4sYG47iou79YSNDwF/+
PkqeeXUUmK9+A7Ste9ON+yVxTidmXunSvJ2ECpigHbjJUw0WjTRK8U6W682e2K2h
TGM6KVi6W8P246wyipeggV3bjhikM3gLITLmcpjgaorhE0WORtzj1acOByPT08e0
w2ixMUjwsZd/QlS/PZaI20jZhO8lDobhteDsnhYgv6ItVmju3Dy7vHeX96eH9hDV
qJOWWLmvNTVnwy0gqVsuAl7JaD1zaCVhmdxHkwyD+qQ0jtsc2Ui83ArrgGPrMmXx
zslVvnYexSbM/nMM33fND9hp7gVsYooWM4yUqGsd7N+oc9V6e9q4l2PfG8QMhDq2
tUNhMo5JDIZUMSYeF4yL7TQuOqqZKMYSEKP7YWIflDct9bMK+n5YTqGV5dowLFhm
14YJ6F7PDJLUbMJKLgZ5zFNE9GnR9kQGiOUpPdhcswVKlU4prOMfHf6OWE1t1O2v
hENYCF67ipIbjMmYJFFECz24HTMAaDA5b0Wcco9nH85ZcBPU5mA=
=kyio
-----END PGP SIGNATURE-----
Riccardo Mottola
Mar 8, 2017, 2:10:02 PM3/8/17
to
Hi,
On 03/08/17 19:40, Konstantinos Margaritis wrote:
>
> Again I don't disagree there, but since it's not a release
> architecture, we could just move on to newer CPUs and change the
> minimum specs -which would IMHO be a good thing, as it would lower the
> number of supported platforms to a much smaller and more manageable
> set. I have enough PowerPC boxes here, but none without Altivec, so
> even if I wanted to, I couldn't even test lack of the feature, and I
> don't care enough to go into the trouble of doing that.
Well, it is very sad we aren't release anymore, IMHO, although a fact.
Yet i think it is wrong raising the bar and excluding many CPUs just
because it makes things easier.
powerpc was (and probably still is) a quite popular debian port and I
know of many who run those coloured iMacs with Debian!
There are also other non-Mac machines. E.g. I am pretty sure the
Linkbook doesn't have altivec and there were a couple of other similar
small netbooks which sadly did not get popular compared to ARM.
Riccardo
On 03/08/17 19:40, Konstantinos Margaritis wrote:
>
> Again I don't disagree there, but since it's not a release
> architecture, we could just move on to newer CPUs and change the
> minimum specs -which would IMHO be a good thing, as it would lower the
> number of supported platforms to a much smaller and more manageable
> set. I have enough PowerPC boxes here, but none without Altivec, so
> even if I wanted to, I couldn't even test lack of the feature, and I
> don't care enough to go into the trouble of doing that.
Yet i think it is wrong raising the bar and excluding many CPUs just
because it makes things easier.
powerpc was (and probably still is) a quite popular debian port and I
know of many who run those coloured iMacs with Debian!
There are also other non-Mac machines. E.g. I am pretty sure the
Linkbook doesn't have altivec and there were a couple of other similar
small netbooks which sadly did not get popular compared to ARM.
Riccardo
Konstantinos Margaritis
Mar 8, 2017, 3:30:02 PM3/8/17
to
Στις 08-03-2017, ημέρα Τετ, και ώρα 20:08 +0100, ο/η Riccardo Mottola
έγραψε:
We do not have the resources of testing on all those platforms, and I
personally know of no Linux powerpc developer that works on a non-
altivec system -except for embedded which is a different case.
In any case, I'm sorry but I still believe that even more so now it's
more important to let go of the older platforms and just increase our
base requirements to enforce Altivec, definitely for powerpc, and
possibly even for ppc64. That way, we might some day, make it back to
release architecture with a smaller set of supported architectures. As
it is, I highly doubt it.
Konstantinos
έγραψε:
> Well, it is very sad we aren't release anymore, IMHO, although a
> fact.
> Yet i think it is wrong raising the bar and excluding many CPUs just
> because it makes things easier.
> powerpc was (and probably still is) a quite popular debian port and
> I
> know of many who run those coloured iMacs with Debian!
>
> There are also other non-Mac machines. E.g. I am pretty sure the
> Linkbook doesn't have altivec and there were a couple of other
> similar
> small netbooks which sadly did not get popular compared to ARM.
I do not disagree on those points, but it's all a matter of resources.
> fact.
> Yet i think it is wrong raising the bar and excluding many CPUs just
> because it makes things easier.
> powerpc was (and probably still is) a quite popular debian port and
> I
> know of many who run those coloured iMacs with Debian!
>
> There are also other non-Mac machines. E.g. I am pretty sure the
> Linkbook doesn't have altivec and there were a couple of other
> similar
> small netbooks which sadly did not get popular compared to ARM.
We do not have the resources of testing on all those platforms, and I
personally know of no Linux powerpc developer that works on a non-
altivec system -except for embedded which is a different case.
In any case, I'm sorry but I still believe that even more so now it's
more important to let go of the older platforms and just increase our
base requirements to enforce Altivec, definitely for powerpc, and
possibly even for ppc64. That way, we might some day, make it back to
release architecture with a smaller set of supported architectures. As
it is, I highly doubt it.
Konstantinos
Konstantinos Margaritis
Mar 8, 2017, 3:30:02 PM3/8/17
to
Στις 08-03-2017, ημέρα Τετ, και ώρα 19:53 +0100, ο/η John Paul Adrian
Glaubitz έγραψε:
revolves around SIMD optimizations in several architectures (Intel,
ARM, Power and S390x ZVector), running highly parallel performance-
critical software (not Physics related since a long time ago). So I
also do have a pretty good idea of what I'm talking about. In any case,
I will agree that Atlas is one of the special cases where you compile
from source, but my original point was against the original bug report
and Firefox, which isn't a special case. A typical user should not have
to rebuild Firefox to get a decent performance increase.
> I am still waiting for the section from the policy. You cannot make
> these
> bold statements and then not come up with the necessary prove.
Not policy, but how about this:
https://www.debian.org/Bugs/Developer#severities
and this:
https://www.debian.org/ports/powerpc/
Currently the systems listed there are assumed to be supported.
The statements are not bold, they are facts, my guess is that many
developer would reply pretty much the same.
> I assume you are aware of the fact that Debian's i386 port requires
> at
> least an i686 CPU these days. How does that fit with your line of
> arguments? According to your logic, all packages would be affected
> by RC bugs because they stopped supporting i386 long time ago.
The i386 port minimum requirements have been increased on a steady
basis. And it's also a fact that runtime detection works much better
there, while at the same time, a simple google search revealed quite a
few bug reports on i386 even for enabling SSE2 (which should be
considered default on most CPUs by now). I don't see how altivec should
be different. The difference is that we're still supporting almost 20
year old hardware -or pretend to support.
> I'm sorry, but this argument contradicts the current practice.
Does it? Look below:
> Again, look at i386.
I did. And I found just from a very quick search #812989, #792594,
#852356, and I guess there are probably many more like those. So I
don't see your point.
> So, you actually don't bother at all and don't want to go through
> any efforts of testing, yet you insist on your stance. Odd.
No, you got half of it. I support the use of Altivec, properly. I'm
testing Altivec code, on Altivec hardware, I don't test Altivec code on
non-altivec hardware, or altivec detection for that matter, not
anymore. And I'm actually tired of pushing for distro-wide enablement
by default.
Anyway, if you're going to continue the discussion just to prove that
altivec should be supported, yes, I completely agree, but I disagree on
the way you propose to do it, enable it until someone complains. Please
allow me to quote the phrase which triggered my reply:
"But it has been like that for ages and no one has complained so far"
If we go your route and noone complains for a long time, that means
noone bothered to run the software in that very old hardware and we're
just limiting the performance for the rest of our users -who have
supporting hardware, for absolutely no good reason. If someone
complains immediately (as they did for ppc64) then that means people
are actually still using powerpc port on non-altivec hardware. What I'm
actually suggesting -now and have been for a long time- is that we
should be more sincere and just admit we cannot support every possible
configuration and we should try to at least support the top range of
the hardware as best as we can, and maybe even give a decent speed bump
by enabling altivec throughout, so in essence I'm advocating -yet once
more, to just declare non-altivec hardware as unsupported and be done
with it. Users of older hardware should just upgrade or use an older
version.
Regards
Konstantinos
Glaubitz έγραψε:
> Actually, it is. ATLAS is one of these libraries which contain lots
> of CPU optimization code and if you really want to use ATLAS for
> actual number crunching, you want to build it from source. It is
> very common practice in the scientific work. I am a graduated
> physicist
> who used to do number crunching on such clusters and I also happened
> to maintain several of such clusters for work.
Good, I'm also a physicist though now my line of work almost entirely
> of CPU optimization code and if you really want to use ATLAS for
> actual number crunching, you want to build it from source. It is
> very common practice in the scientific work. I am a graduated
> physicist
> who used to do number crunching on such clusters and I also happened
> to maintain several of such clusters for work.
revolves around SIMD optimizations in several architectures (Intel,
ARM, Power and S390x ZVector), running highly parallel performance-
critical software (not Physics related since a long time ago). So I
also do have a pretty good idea of what I'm talking about. In any case,
I will agree that Atlas is one of the special cases where you compile
from source, but my original point was against the original bug report
and Firefox, which isn't a special case. A typical user should not have
to rebuild Firefox to get a decent performance increase.
> I am still waiting for the section from the policy. You cannot make
> these
> bold statements and then not come up with the necessary prove.
https://www.debian.org/Bugs/Developer#severities
and this:
https://www.debian.org/ports/powerpc/
Currently the systems listed there are assumed to be supported.
The statements are not bold, they are facts, my guess is that many
developer would reply pretty much the same.
> I assume you are aware of the fact that Debian's i386 port requires
> at
> least an i686 CPU these days. How does that fit with your line of
> arguments? According to your logic, all packages would be affected
> by RC bugs because they stopped supporting i386 long time ago.
basis. And it's also a fact that runtime detection works much better
there, while at the same time, a simple google search revealed quite a
few bug reports on i386 even for enabling SSE2 (which should be
considered default on most CPUs by now). I don't see how altivec should
be different. The difference is that we're still supporting almost 20
year old hardware -or pretend to support.
> I'm sorry, but this argument contradicts the current practice.
> Again, look at i386.
I did. And I found just from a very quick search #812989, #792594,
#852356, and I guess there are probably many more like those. So I
don't see your point.
> So, you actually don't bother at all and don't want to go through
> any efforts of testing, yet you insist on your stance. Odd.
testing Altivec code, on Altivec hardware, I don't test Altivec code on
non-altivec hardware, or altivec detection for that matter, not
anymore. And I'm actually tired of pushing for distro-wide enablement
by default.
Anyway, if you're going to continue the discussion just to prove that
altivec should be supported, yes, I completely agree, but I disagree on
the way you propose to do it, enable it until someone complains. Please
allow me to quote the phrase which triggered my reply:
"But it has been like that for ages and no one has complained so far"
noone bothered to run the software in that very old hardware and we're
just limiting the performance for the rest of our users -who have
supporting hardware, for absolutely no good reason. If someone
complains immediately (as they did for ppc64) then that means people
are actually still using powerpc port on non-altivec hardware. What I'm
actually suggesting -now and have been for a long time- is that we
should be more sincere and just admit we cannot support every possible
configuration and we should try to at least support the top range of
the hardware as best as we can, and maybe even give a decent speed bump
by enabling altivec throughout, so in essence I'm advocating -yet once
more, to just declare non-altivec hardware as unsupported and be done
with it. Users of older hardware should just upgrade or use an older
version.
Regards
Konstantinos
Karoly Balogh (Charlie/SGR)
Mar 8, 2017, 3:50:03 PM3/8/17
to
Hi,
On Wed, 8 Mar 2017, Konstantinos Margaritis wrote:
> > There are also other non-Mac machines. E.g. I am pretty sure the
> > Linkbook doesn't have altivec and there were a couple of other
> > similar small netbooks which sadly did not get popular compared to
> > ARM.
>
> I do not disagree on those points, but it's all a matter of resources.
> We do not have the resources of testing on all those platforms, and I
> personally know of no Linux powerpc developer that works on a non-
> altivec system -except for embedded which is a different case.
I'm pretty sure A-Eon, who are selling the AmigaOne X5000 based on an
e5500 core, funds the work of some Linux people to keep Debian up to date
for that system. And that's a pretty juicy multicore desktop machine, with
PCIe slots, RadeonHD videocards and everything, yet no Altivec.
Based on their earlier activities, I'd guess A-Eon would be willing to
support the right person with hardware, if this makes the difference.
> In any case, I'm sorry but I still believe that even more so now it's
> more important to let go of the older platforms and just increase our
> base requirements to enforce Altivec, definitely for powerpc, and
> possibly even for ppc64. That way, we might some day, make it back to
> release architecture with a smaller set of supported architectures. As
> it is, I highly doubt it.
I think until some larger company backs it, or there's mass demand, like
with other release versions, it won't happen anyway. I agree though, that
the target needs to be redefined, other than "keep those old Macs running
somehow".
But it's still ironic in the light of this discussion that one of, if not
the strongest desktop PPC box one can buy these days has no Altivec. And
there are much smaller OSes than Linux which somehow still manage to
handle this situation.
Just my two cents...
Charlie
On Wed, 8 Mar 2017, Konstantinos Margaritis wrote:
> > There are also other non-Mac machines. E.g. I am pretty sure the
> > Linkbook doesn't have altivec and there were a couple of other
> > similar small netbooks which sadly did not get popular compared to
> > ARM.
>
> I do not disagree on those points, but it's all a matter of resources.
> We do not have the resources of testing on all those platforms, and I
> personally know of no Linux powerpc developer that works on a non-
> altivec system -except for embedded which is a different case.
e5500 core, funds the work of some Linux people to keep Debian up to date
for that system. And that's a pretty juicy multicore desktop machine, with
PCIe slots, RadeonHD videocards and everything, yet no Altivec.
Based on their earlier activities, I'd guess A-Eon would be willing to
support the right person with hardware, if this makes the difference.
> In any case, I'm sorry but I still believe that even more so now it's
> more important to let go of the older platforms and just increase our
> base requirements to enforce Altivec, definitely for powerpc, and
> possibly even for ppc64. That way, we might some day, make it back to
> release architecture with a smaller set of supported architectures. As
> it is, I highly doubt it.
with other release versions, it won't happen anyway. I agree though, that
the target needs to be redefined, other than "keep those old Macs running
somehow".
But it's still ironic in the light of this discussion that one of, if not
the strongest desktop PPC box one can buy these days has no Altivec. And
there are much smaller OSes than Linux which somehow still manage to
handle this situation.
Just my two cents...
Charlie
John Paul Adrian Glaubitz
Mar 8, 2017, 4:00:02 PM3/8/17
to
On 03/08/2017 09:45 PM, Karoly Balogh (Charlie/SGR) wrote:
> I'm pretty sure A-Eon, who are selling the AmigaOne X5000 based on an
> e5500 core, funds the work of some Linux people to keep Debian up to date
> for that system. And that's a pretty juicy multicore desktop machine, with
> PCIe slots, RadeonHD videocards and everything, yet no Altivec.
I actually have two Tabor A1222 boards from them which I set up as buildds
> I'm pretty sure A-Eon, who are selling the AmigaOne X5000 based on an
> e5500 core, funds the work of some Linux people to keep Debian up to date
> for that system. And that's a pretty juicy multicore desktop machine, with
> PCIe slots, RadeonHD videocards and everything, yet no Altivec.
for the powerpcspe port. One of the boards is broken and I have been waiting
for a replacements for months now.
> Based on their earlier activities, I'd guess A-Eon would be willing to
> support the right person with hardware, if this makes the difference.
I still haven't got a replacement for the second board yet :(.
> I think until some larger company backs it, or there's mass demand, like
> with other release versions, it won't happen anyway. I agree though, that
> the target needs to be redefined, other than "keep those old Macs running
> somehow".
a big company. When I talked with IBM people, they said they basically don't
care about 32-Bit PowerPC anymore although they are still doing some bug
fixing, but things like a golang port for 32-Bit PowerPC won't happen.
At least there is a ppc64 (POWER5) port of golang.
> But it's still ironic in the light of this discussion that one of, if not
> the strongest desktop PPC box one can buy these days has no Altivec. And
> there are much smaller OSes than Linux which somehow still manage to
> handle this situation.
don't make much sense anyways. Do these smaller OS even support applications
like mplayer, Firefox or GIMP?
Lennart Sorensen
Mar 8, 2017, 4:00:03 PM3/8/17
to
On Wed, Mar 08, 2017 at 08:08:59PM +0100, Riccardo Mottola wrote:
> Well, it is very sad we aren't release anymore, IMHO, although a fact.
> Yet i think it is wrong raising the bar and excluding many CPUs just because
> it makes things easier.
> powerpc was (and probably still is) a quite popular debian port and I know
> of many who run those coloured iMacs with Debian!
>
> There are also other non-Mac machines. E.g. I am pretty sure the Linkbook
> doesn't have altivec and there were a couple of other similar small netbooks
> which sadly did not get popular compared to ARM.
This is a current in production machine:
> Well, it is very sad we aren't release anymore, IMHO, although a fact.
> Yet i think it is wrong raising the bar and excluding many CPUs just because
> it makes things easier.
> powerpc was (and probably still is) a quite popular debian port and I know
> of many who run those coloured iMacs with Debian!
>
> There are also other non-Mac machines. E.g. I am pretty sure the Linkbook
> doesn't have altivec and there were a couple of other similar small netbooks
> which sadly did not get popular compared to ARM.
http://www.amigaos.net/hardware/133/amigaone-x5000
No altivec. Not an old CPU.
--
Len Sorensen
John Paul Adrian Glaubitz
Mar 8, 2017, 4:00:03 PM3/8/17
to
On 03/08/2017 09:52 PM, Lennart Sorensen wrote:
> This is a current in production machine:
>
> http://www.amigaos.net/hardware/133/amigaone-x5000
>
> No altivec. Not an old CPU.
With the pricetag of a Macbook Pro Retina:
> This is a current in production machine:
>
> http://www.amigaos.net/hardware/133/amigaone-x5000
>
> No altivec. Not an old CPU.
> http://amigaonthelake.com/amigaone-x5000-first-encounters-motherboard-bundle/
Karoly Balogh (Charlie/SGR)
Mar 8, 2017, 4:20:02 PM3/8/17
to
Hi,
On Wed, 8 Mar 2017, John Paul Adrian Glaubitz wrote:
> > I'm pretty sure A-Eon, who are selling the AmigaOne X5000 based on an
> > e5500 core, funds the work of some Linux people to keep Debian up to date
> > for that system. And that's a pretty juicy multicore desktop machine, with
> > PCIe slots, RadeonHD videocards and everything, yet no Altivec.
>
> I actually have two Tabor A1222 boards from them which I set up as buildds
> for the powerpcspe port. One of the boards is broken and I have been waiting
> for a replacements for months now.
Right. Although the Tabor is not in production yet and never went on sale
officially, because they're waiting for the AmigaOS4.1 developers to pull
together some semi-working system for the machine. As it supposed to sell
bundled...
> > Based on their earlier activities, I'd guess A-Eon would be willing to
> > support the right person with hardware, if this makes the difference.
>
> I'm not sure how serious they are with these efforts given the fact that
> I still haven't got a replacement for the second board yet :(.
Indeed. Actually the X5000 seems out of stock everywhere, and A-Eon is
quite silent these days. But if not them, then no one, at this point, I'd
say.
> > I think until some larger company backs it, or there's mass demand, like
> > with other release versions, it won't happen anyway. I agree though, that
> > the target needs to be redefined, other than "keep those old Macs running
> > somehow".
>
> This is pretty much the key issue. It lacks support from the community and
> a big company. When I talked with IBM people, they said they basically don't
> care about 32-Bit PowerPC anymore although they are still doing some bug
> fixing, but things like a golang port for 32-Bit PowerPC won't happen.
> At least there is a ppc64 (POWER5) port of golang.
You mean the Go developers require a company backing a port to accept it
mainline, or just the usual case - there are zero people with both Go and
PowerPC interest?
> > But it's still ironic in the light of this discussion that one of, if not
> > the strongest desktop PPC box one can buy these days has no Altivec. And
> > there are much smaller OSes than Linux which somehow still manage to
> > handle this situation.
>
> This isn't "Linux", it's a single application for which non-Altivec variants
> don't make much sense anyways.
I was referring to the idea of restricting the entire Debian PPC port to
Altivec only.
> Do these smaller OS even support applications like mplayer, Firefox or
> GIMP?
Yes and no. :)
Both MorphOS and AmigaOS4 has a heavily customized MPlayer port, and at
least the MorphOS version has runtime Altivec detection. MorphOS supports
runtime Altivec detection elsewhere in the system too, like various JPEG
and other format decoders, Ogg, MP3, FFMPEG for video-thumbnail icons in
the desktop, whatnot. They also have their own set of custom Altivec
optimizations here and there. And no, no Firefox, but there's a WebKit
based browser called OWB, with a custom mediaplayer subsystem (based on
FFMPEG, et.al.), which can do Altivec with runtime detecion as well, if
I'm not mistaken.
And the last two platforms added to MorphOS, the ACube's Sam460 and the
A-Eon A1 X5000 have no Altivec, while most users are still on old Macs,
with Altivec. The details might vary, but the situation is similar with
OS4 too.
Charlie
On Wed, 8 Mar 2017, John Paul Adrian Glaubitz wrote:
> > I'm pretty sure A-Eon, who are selling the AmigaOne X5000 based on an
> > e5500 core, funds the work of some Linux people to keep Debian up to date
> > for that system. And that's a pretty juicy multicore desktop machine, with
> > PCIe slots, RadeonHD videocards and everything, yet no Altivec.
>
> I actually have two Tabor A1222 boards from them which I set up as buildds
> for the powerpcspe port. One of the boards is broken and I have been waiting
> for a replacements for months now.
officially, because they're waiting for the AmigaOS4.1 developers to pull
together some semi-working system for the machine. As it supposed to sell
bundled...
> > Based on their earlier activities, I'd guess A-Eon would be willing to
> > support the right person with hardware, if this makes the difference.
>
> I'm not sure how serious they are with these efforts given the fact that
> I still haven't got a replacement for the second board yet :(.
quite silent these days. But if not them, then no one, at this point, I'd
say.
> > I think until some larger company backs it, or there's mass demand, like
> > with other release versions, it won't happen anyway. I agree though, that
> > the target needs to be redefined, other than "keep those old Macs running
> > somehow".
>
> This is pretty much the key issue. It lacks support from the community and
> a big company. When I talked with IBM people, they said they basically don't
> care about 32-Bit PowerPC anymore although they are still doing some bug
> fixing, but things like a golang port for 32-Bit PowerPC won't happen.
> At least there is a ppc64 (POWER5) port of golang.
mainline, or just the usual case - there are zero people with both Go and
PowerPC interest?
> > But it's still ironic in the light of this discussion that one of, if not
> > the strongest desktop PPC box one can buy these days has no Altivec. And
> > there are much smaller OSes than Linux which somehow still manage to
> > handle this situation.
>
> This isn't "Linux", it's a single application for which non-Altivec variants
> don't make much sense anyways.
Altivec only.
> Do these smaller OS even support applications like mplayer, Firefox or
> GIMP?
Both MorphOS and AmigaOS4 has a heavily customized MPlayer port, and at
least the MorphOS version has runtime Altivec detection. MorphOS supports
runtime Altivec detection elsewhere in the system too, like various JPEG
and other format decoders, Ogg, MP3, FFMPEG for video-thumbnail icons in
the desktop, whatnot. They also have their own set of custom Altivec
optimizations here and there. And no, no Firefox, but there's a WebKit
based browser called OWB, with a custom mediaplayer subsystem (based on
FFMPEG, et.al.), which can do Altivec with runtime detecion as well, if
I'm not mistaken.
And the last two platforms added to MorphOS, the ACube's Sam460 and the
A-Eon A1 X5000 have no Altivec, while most users are still on old Macs,
with Altivec. The details might vary, but the situation is similar with
OS4 too.
Charlie
John Paul Adrian Glaubitz
Mar 8, 2017, 4:40:02 PM3/8/17
to
On 03/08/2017 10:16 PM, Karoly Balogh (Charlie/SGR) wrote:
> Right. Although the Tabor is not in production yet and never went on sale
> officially, because they're waiting for the AmigaOS4.1 developers to pull
> together some semi-working system for the machine. As it supposed to sell
> bundled...
Interesting. I had heard that there will be a AmigaOS4 port but I wasn't
> Right. Although the Tabor is not in production yet and never went on sale
> officially, because they're waiting for the AmigaOS4.1 developers to pull
> together some semi-working system for the machine. As it supposed to sell
> bundled...
aware that they were waiting for the port to be released. The boards itself
are pretty nice though.
> Indeed. Actually the X5000 seems out of stock everywhere, and A-Eon is
> quite silent these days. But if not them, then no one, at this point, I'd
> say.
> You mean the Go developers require a company backing a port to accept it
> mainline, or just the usual case - there are zero people with both Go and
> PowerPC interest?
by IBM people. I asked them about 32-Bit PowerPC and they said that it's too
old for them to care about it.
> I was referring to the idea of restricting the entire Debian PPC port to
> Altivec only.
anyway. The packages which support Altivec, are probably better off with
Altivec enabled anyway.
> Both MorphOS and AmigaOS4 has a heavily customized MPlayer port, and at
> least the MorphOS version has runtime Altivec detection.
> And no, no Firefox, but there's a WebKit
> based browser called OWB, with a custom mediaplayer subsystem (based on
> FFMPEG, et.al.), which can do Altivec with runtime detecion as well, if
> I'm not mistaken.
machines sitting in the basement. I also happen to maintain Debian's
m68k port and managed to bump it to 10,500 built packages, including
Firefox and LibreOffice :).
> And the last two platforms added to MorphOS, the ACube's Sam460 and the
> A-Eon A1 X5000 have no Altivec, while most users are still on old Macs,
> with Altivec. The details might vary, but the situation is similar with
> OS4 too.
Morphos. It currently runs an outdated installation of Debian unstable
as it's currently put into storage.
Karoly Balogh (Charlie/SGR)
Mar 8, 2017, 5:00:02 PM3/8/17
to
Hi,
On Wed, 8 Mar 2017, John Paul Adrian Glaubitz wrote:
On Wed, 8 Mar 2017, John Paul Adrian Glaubitz wrote:
> Interesting. I had heard that there will be a AmigaOS4 port but I wasn't
> aware that they were waiting for the port to be released. The boards itself
> are pretty nice though.
Yeah. I was quite tempted to get one, and replace my old DebianPPC Pegasos
> aware that they were waiting for the port to be released. The boards itself
> are pretty nice though.
II/G4 with it, but then I had to move to a different city, and my Pegasos
II/G4 server was replaced by a Raspberry Pi 2 instead, which is much more
lightweight to carry around, and actually fine for what I need it (mostly
just low bandwidth tunneling, backups to an external drive, and a terminal
IRC client)...
I also considered adding SPE support to the Free Pascal PowerPC port, as I
happen to be a maintainer of the m68k port, so I know the compiler
internals, but I wasn't convinced there was enough demand, and also I
wanted to keep the leftovers of my sanity... (Which is not a lot, I
admit... :)
> > You mean the Go developers require a company backing a port to accept it
> > mainline, or just the usual case - there are zero people with both Go and
> > PowerPC interest?
>
> Both the ppc64el (POWER8) and the ppc64 (POWER5) port are maintained directly
> by IBM people. I asked them about 32-Bit PowerPC and they said that it's too
> old for them to care about it.
PowerPC cores for servers, and even for supercomputers, but of course
every company is trying to get rid of its legacy stuff - which is
everything which the management decided that it probably won't drive
future sales...
> Yeah, I know of OWB. I'm actually a huge Amiga fan with tons of Amiga
> machines sitting in the basement. I also happen to maintain Debian's
> m68k port and managed to bump it to 10,500 built packages, including
> Firefox and LibreOffice :).
We might have plenty to talk about... ;)
> > And the last two platforms added to MorphOS, the ACube's Sam460 and the
> > A-Eon A1 X5000 have no Altivec, while most users are still on old Macs,
> > with Altivec. The details might vary, but the situation is similar with
> > OS4 too.
>
> I have a Mac Mini G4 for which I have been planning to buy a license of
> Morphos. It currently runs an outdated installation of Debian unstable
> as it's currently put into storage.
machines. Though hardly more than one of my 15" PowerBook G4s is in use
these days, except before releases. :(
Charlie
Riccardo Mottola
Mar 8, 2017, 5:50:02 PM3/8/17
to
Hi Konstantinos,
Konstantinos Margaritis wrote:
> I do not disagree on those points, but it's all a matter of resources.
> We do not have the resources of testing on all those platforms, and I
> personally know of no Linux powerpc developer that works on a non-
> altivec system -except for embedded which is a different case.
define "developer" - I am not a debian developer, but I am definitely an
open-source developer and take proudly care of supporting most
architectures I can and have access to. All the GNUstep stuff I have
access to, maintain or even write myself.
That goes from FTP applications up to 2D FFTs on Images, convolutions,
filters, etc.
Actually, I use my iBook mostly for that - development and testing. To
Browse the web I use x86 or amd64 nowadays.
It is a fact that the PPC port is mostly about "old macs" so the age of
our HW is older for most!
However I do run debian also on older x86 hardware without the newest
SSE2/SSE3 stuff and it runs. I even have NetBSD on an original Pentium
system and it does work. Apparently most software still copes better
with various x86 differences than e.g. G3 vs G4.
Currently however, I consider my iBook fully functional - except for the
glitch with the newer kernels breaking ATI xorg, but that is a different
question from here.
I go further: all the people I know that use PPC use it on older Mac or
Amiga boards. Not cool IBM machines. There is a lot of different
usage... from embedded to datacenters!
Riccardo
Konstantinos Margaritis wrote:
> I do not disagree on those points, but it's all a matter of resources.
> We do not have the resources of testing on all those platforms, and I
> personally know of no Linux powerpc developer that works on a non-
> altivec system -except for embedded which is a different case.
open-source developer and take proudly care of supporting most
architectures I can and have access to. All the GNUstep stuff I have
access to, maintain or even write myself.
That goes from FTP applications up to 2D FFTs on Images, convolutions,
filters, etc.
Actually, I use my iBook mostly for that - development and testing. To
Browse the web I use x86 or amd64 nowadays.
It is a fact that the PPC port is mostly about "old macs" so the age of
our HW is older for most!
However I do run debian also on older x86 hardware without the newest
SSE2/SSE3 stuff and it runs. I even have NetBSD on an original Pentium
system and it does work. Apparently most software still copes better
with various x86 differences than e.g. G3 vs G4.
Currently however, I consider my iBook fully functional - except for the
glitch with the newer kernels breaking ATI xorg, but that is a different
question from here.
I go further: all the people I know that use PPC use it on older Mac or
Amiga boards. Not cool IBM machines. There is a lot of different
usage... from embedded to datacenters!
Riccardo
Christian Zigotzky
Mar 9, 2017, 4:10:03 AM3/9/17
to
On 08 March 2017 at 10:29 PM, John Paul Adrian Glaubitz wrote:
>
> Interesting. I had heard that there will be a AmigaOS4 port but I wasn't
> aware that they were waiting for the port to be released. The boards itself
> are pretty nice though.
>
>> Indeed. Actually the X5000 seems out of stock everywhere, and A-Eon is
>> quite silent these days. But if not them, then no one, at this point, I'd
>> say.
> I agree.
>
Dear mailing list subscribers,
>
> Interesting. I had heard that there will be a AmigaOS4 port but I wasn't
> aware that they were waiting for the port to be released. The boards itself
> are pretty nice though.
>
>> Indeed. Actually the X5000 seems out of stock everywhere, and A-Eon is
>> quite silent these days. But if not them, then no one, at this point, I'd
>> say.
> I agree.
>
Sorry because of our missing responses in this mailing list. We usually
read this list but sometimes we have a lot of work and it is not
possible to response to any emails.
I am Christian Zigotzky and I am a member of the A-EON Technology Linux
support team and additionally I am AmigaOS 4.1 beta tester. I joined the
A-EON Technology Linux support team in 2013. We provide Linux kernel and
distribution support for all motherboards manufactured by A-EON. [1]
All A-EON motherboards were designed for AmigaOS 4.1 [2]. This means,
AmigaOS 4.1 is the main operating system on our NG Amigas. Additionally
we offer Linux as a second operating system for our NG Amigas.
We aren't really silent these days. [3]
In the Linux support team we are working on some projects currently. We
are creating a new Linux distribution called 'MATE PowerPC Remix 2017'
because Ubuntu has dropped the support for PowerPC. Additionally we are
integrating support for our AmigaOne X1000 to the official Linux kernel
currently. Every day, we work hard to offer a good Linux support for our
motherboards but our main work is to improve AmigaOS 4.1.
AmigaOS 4.1 has overtaken Linux PPC on our systems. It supports hardware
3D acceleration for modern Radeon graphics cards and it is developed for
PowerPC directly. This means it is not just a port. It is directly
designed for PowerPC systems. It is very fast and reliable. The Odyssey
web browser is the fastest web browser on our NG Amigas. It is faster
than all Linux web browsers and you can also browse on web sites like
Facebook, YouTube, and Google+ without any problems.
Sometimes our customers use Linux PPC because of software which do not
exist on Amiga OS4.1. With Linux, our customers have the possibility to
replace their main PC or Mac.
If you have any questions, please do not hesitate to contact our team.
Best regards,
Christian Zigotzky
A-EON Core Linux Development und Support Team
Part of A-EON Technology Ltd, Cardiff. United Kingdom
http://www.a-eon.com
http://www.a-eon.com/?page=contact
[1]
https://plus.google.com/u/0/115515624056477014971
http://www.supertuxkart-amiga.de/amiga/x1000.html
http://forum.hyperion-entertainment.biz/viewforum.php?f=35&sid=525246aabe3257df3bfe130a02dbb286
http://forum.hyperion-entertainment.biz/viewforum.php?f=58&sid=525246aabe3257df3bfe130a02dbb286
http://forum.hyperion-entertainment.biz/viewforum.php?f=52&sid=525246aabe3257df3bfe130a02dbb286
[2]
http://www.amigaos.net/
[3]
https://www.facebook.com/AEonTechnologyLtd/
http://blog.a-eon.biz/blog/
http://blog.hyperion-entertainment.biz/
John Paul Adrian Glaubitz
Mar 9, 2017, 4:30:02 AM3/9/17
to
On 03/09/2017 10:02 AM, Christian Zigotzky wrote:
> AmigaOS 4.1 has overtaken Linux PPC on our systems. It supports hardware
> 3D acceleration for modern Radeon graphics cards
Graphics support on Linux is more or less independent of the underlying
> AmigaOS 4.1 has overtaken Linux PPC on our systems. It supports hardware
> 3D acceleration for modern Radeon graphics cards
hardware (minus some endianness issues). Normally all drivers which work
on Linux x86 platforms should work on PowerPC platforms as well. There
is less testing however, so you might run into bugs more often than
on x86.
> and it is developed for PowerPC directly. This means it is not just a port.
> It is directly designed for PowerPC systems. It is very fast and reliable.
is a dying architecture, you basically can buy embedded systems these days
only which are far behind of modern ARM and x86 systems. Building an operating
system without portability in mind means that you don't have a perspective for
the foreseeable future.
Locking yourself in to one architecture means you are stuck with old hardware
the moment the chip vendors stop the production. At least ARM support would
have been desirable, to be honest.
> The Odyssey web browser is the fastest web browser on our NG Amigas. It is
> faster than all Linux web browsers and you can also browse on web sites
> like Facebook, YouTube, and Google+ without any problems.
> Sometimes our customers use Linux PPC because of software which do not exist
> on Amiga OS4.1. With Linux, our customers have the possibility to replace their
> main PC or Mac.
Karoly Balogh (Charlie/SGR)
Mar 9, 2017, 4:50:02 AM3/9/17
to
Hi,
On Thu, 9 Mar 2017, Christian Zigotzky wrote:
> AmigaOS 4.1 has overtaken Linux PPC on our systems. (...) It is very
> fast and reliable.
You don't want to get me started on the "fast and reliable" statement,
really...
But at least I personally need Linux for a completely different purposen,
than my NG Amiga systems, most of which OS4 (or other NG Amiga-like OSes)
are unable to deliver.
Additonally, most sane NG Amiga developers use crosscompiling tools
heavily these days. Usually hosted on Linux (or similar Un*x systems)...
Although usually that means x86/x64 Linux, for performance reasons, not
PPC.
> The Odyssey web browser is the fastest web browser on our NG Amigas.
And it is originally a port... from MorphOS.
> It is faster than all Linux web browsers
And the engine is a port... heavily based on libraries ported from Linux
and elswehere.
> and you can also browse on web sites like Facebook, YouTube, and Google+
> without any problems.
That is not strictly true, especially the "without any problems" part.
But it works reasonably well, there I agree. Sadly, it's WebKit engine is
lagging behind as others pointed out.
> If you have any questions, please do not hesitate to contact our team.
Thanks. It was a nice markeking speech, but didn't really address the
questions asked already. For example hardware availability issues.
(Hardware seems out of stock everywhere?)
Charlie
On Thu, 9 Mar 2017, Christian Zigotzky wrote:
> AmigaOS 4.1 has overtaken Linux PPC on our systems. (...) It is very
> fast and reliable.
You don't want to get me started on the "fast and reliable" statement,
really...
But at least I personally need Linux for a completely different purposen,
than my NG Amiga systems, most of which OS4 (or other NG Amiga-like OSes)
are unable to deliver.
Additonally, most sane NG Amiga developers use crosscompiling tools
heavily these days. Usually hosted on Linux (or similar Un*x systems)...
Although usually that means x86/x64 Linux, for performance reasons, not
PPC.
> The Odyssey web browser is the fastest web browser on our NG Amigas.
> It is faster than all Linux web browsers
and elswehere.
> and you can also browse on web sites like Facebook, YouTube, and Google+
> without any problems.
But it works reasonably well, there I agree. Sadly, it's WebKit engine is
lagging behind as others pointed out.
> If you have any questions, please do not hesitate to contact our team.
questions asked already. For example hardware availability issues.
(Hardware seems out of stock everywhere?)
Charlie
Christian Zigotzky
Mar 9, 2017, 5:20:03 AM3/9/17
to
On 09 March 2017 at 10:46 AM, Karoly Balogh (Charlie/SGR) wrote:
> Thanks. It was a nice markeking speech, but didn't really address the
> questions asked already. For example hardware availability issues.
> (Hardware seems out of stock everywhere?)
> Charlie
Dear Charlie,
> Thanks. It was a nice markeking speech, but didn't really address the
> questions asked already. For example hardware availability issues.
> (Hardware seems out of stock everywhere?)
> Charlie
The AmigaOne X5000 can be ordered directly from A-EON Technology or from
one of the approved Amiga retailers in the following countries:
- UK: AmigaKit
- USA: Amiga on the Lake
- Germany: Alinea Computer
- Italy: ACube srl
- Switzerland & France: Relec
- France: AMedia computer
- Scandinavia: GGS Data
- Worldwide: A-EON Technology
Please contact the Amiga retailers via email directly.
In addition special, OEM bundles of A-EON software can also be purchased
with the Close Encounters system. Anyone who previously registered their
interest in purchasing an AmigaOne X5000 will be contacted by A-EON
Technology or their approved Amiga retailer. If you are not contacted
please send an email to: con...@a-eon.com and if your local retailer is
not an official distributor tell them to contact A-EON at the same email
address.
Karoly Balogh (Charlie/SGR)
Mar 9, 2017, 7:10:02 AM3/9/17
to
Hi,
On Thu, 9 Mar 2017, luigi burdo wrote:
> I can say for sure one thing. AmigaOs4 have one "external" library that
> work better than Mesa linux too.
>
> It is the warp3d nova who dont have endianess in colors and work with
> all RadeonSI gpus
You are comparing apples to oranges. Warp3D Nove is a low level gateway to
the GPU's shader processors, and some external (as in: it's a separate
executable, IIRC) shader compiler tool added to it (which is BTW, only a
port of Kronos' SPIR-V compiler), plus an optional OpenGL ES2 layer on top
of it. It's a much much much simpler stack than a full fledged MESA
implementation. Also, it was done by the same guy who wrote the Radeon
driver underneath, and it only supports a single GPU family so far, which
also makes everything a lot simpler.
But what makes the real difference, it has a dedicated maintainer, which
is not true for MESA, or GPU drivers on (big endian) Linux/PowerPC.
As it is now, Warp3D Nova might deliver more impressive results for home
users with toys and games on a specific hardware, but not suitable to
support large CAD/CAM and professional 3D software, and doesn't serve as a
quasi-reference open source implementation for an all-industry graphics
standard.
Charlie
On Thu, 9 Mar 2017, luigi burdo wrote:
> I can say for sure one thing. AmigaOs4 have one "external" library that
> work better than Mesa linux too.
>
> It is the warp3d nova who dont have endianess in colors and work with
> all RadeonSI gpus
You are comparing apples to oranges. Warp3D Nove is a low level gateway to
the GPU's shader processors, and some external (as in: it's a separate
executable, IIRC) shader compiler tool added to it (which is BTW, only a
port of Kronos' SPIR-V compiler), plus an optional OpenGL ES2 layer on top
of it. It's a much much much simpler stack than a full fledged MESA
implementation. Also, it was done by the same guy who wrote the Radeon
driver underneath, and it only supports a single GPU family so far, which
also makes everything a lot simpler.
But what makes the real difference, it has a dedicated maintainer, which
is not true for MESA, or GPU drivers on (big endian) Linux/PowerPC.
As it is now, Warp3D Nova might deliver more impressive results for home
users with toys and games on a specific hardware, but not suitable to
support large CAD/CAM and professional 3D software, and doesn't serve as a
quasi-reference open source implementation for an all-industry graphics
standard.
Charlie
0 new messages