> * Stephen Gallagher:
>
>
> Can we make this happen at the RPM level? So that third-party RPMs
> install just fine even though the operating system is something else
> (not x86_64 anymore)? I do not see many explicit dependencies on
> anything “x86_64” in Fedora 30, so perhaps this is doable,
Dave Love wrote:
> I forget the details, but libxsmm is something that depends on an
> instruction introduced with SSE3, and is a good example of portable
> performance engineering over a wide range of (x86_64) processors.
According to the documentation, libxsmm actually also supports a
> > I disagree with ANY raised vector instruction requirement, considering that:
> > * it would make Fedora incompatible with some hardware out there,
>
> That's already so for hardware which is at least of similar age to
> SSE2-only x86_64, i.e. POWER7; my build logs show -mcpu=power8.
For
Frantisek Zatloukal writes:
> On Wed, Jul 31, 2019 at 11:00 AM Kevin Kofler
> wrote:
>
>> * the performance increase to be had is marginal, given that we are mostly
>> talking about code written in C or C++ without even compiler
>> vectorization
>> (-ftree-vectorize) turned on,
>>
>
> Are
I don't agree with the proposal, and am only interested in EPEL, but:
Kevin Kofler writes:
> I disagree with ANY raised vector instruction requirement, considering that:
> * it would make Fedora incompatible with some hardware out there,
That's already so for hardware which is at least of
On Wed, 31 Jul 2019 at 09:15, Frantisek Zatloukal
wrote:
> Personally, I am not at all against raising the bar for baseline x86_64.
> Of course, it'd be ideal to have some sort of derived x86_64_avx arch, but
> if we find out it'd require too much of an investment into infra/releng,
> I'd be +1
Personally, I am not at all against raising the bar for baseline x86_64. Of
course, it'd be ideal to have some sort of derived x86_64_avx arch, but if
we find out it'd require too much of an investment into infra/releng, I'd
be +1 for just changing the base x86_64. Sure, it'd make sense to
Panu Matilainen wrote:
> This proposal seems mostly like an experiment in disguise to find out
> whether the Fedora developers can agree on *something*,
This also looks to me like the tactic to ask for the moon to get a
"compromise" that is still unacceptable.
> and quite clearly the answer is
On 7/22/19 9:51 PM, Ben Cotton wrote:
After preliminary discussions with CPU vendors, we propose AVX2 as the
new baseline. AVX2 support was introduced into CPUs from 2013 to
2015. See
[https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX2
CPUs with AVX2].
This proposal
> "FW" == Florian Weimer writes:
FW> ELF multilib DSOs inside RPMs result in code deduplication,
FW> affecting container image size.
I think it's important to quantify this kind of thing. I think we can
all agree that there is very little benefit to duplicating every single
library, so
On Wed, Jul 24, 2019 at 1:07 PM Florian Weimer wrote:
>
> * Stephen Gallagher:
>
> > With my FESCo hat on, I can't support this action as currently stated.
> > I think I'd be more inclined to consider it if the Change was proposed
> > as a new architecture bring-up. Effectively, this would be a
* Stephen Gallagher:
> With my FESCo hat on, I can't support this action as currently stated.
> I think I'd be more inclined to consider it if the Change was proposed
> as a new architecture bring-up. Effectively, this would be a whole new
> architecture that would just happen to be largely
On Tue, Jul 23, 2019 at 7:37 PM Adam Williamson
wrote:
>
> On Tue, 2019-07-23 at 13:32 -0400, Josh Boyer wrote:
> > On Tue, Jul 23, 2019 at 12:39 PM Kevin Fenzi wrote:
> > > On 7/22/19 10:34 PM, Igor Gnatenko wrote:
> > > > On Tue, Jul 23, 2019 at 4:31 AM Igor Gnatenko
> > > > wrote:
> > > >
> Le mar. 23 juil. 2019 à 08:30, Igor Gnatenko
> > * Define new architecture in RPM/libsolv (let's call it "haswell" or
>> "x86_64modern")
> x86_64avx2 ? or even avx2 ?
SOMETHING, though. I can't be the only one here old enough to remember when
Linux packages came in .i386, .i486, .i586, and
On 7/23/19 7:52 AM, Andrew Lutomirski wrote:
>
> In the interest of a productive discussion, could we maybe focus on what
> the benefits are, both of changing the baseline in general and of
> enabling any particular features?
As someone whose software heavily depends on SSE and AVX2 assembly
Andrew Lutomirski wrote:
> Features like SSE2: enabling SSE2 as the basic floating point mechanism
> changes the ABI drastically. But x86_64 already requires SSE2, so this is
> irrelevant.
For what it's worth, only the x86_64 ABI actually makes use of this. For
i686 (32-bit), even when Fedora
On Tue, Jul 23, 2019 at 7:14 PM Kevin Kofler wrote:
>
> Peter Robinson wrote:
> > The problem with that is getting someone to do the work. The whole
> > reason that the i686 kernel was retired was due to people not stepping
> > up to do the maintenance of the kernel, and the kernel alone. Having
Peter Robinson wrote:
> The problem with that is getting someone to do the work. The whole
> reason that the i686 kernel was retired was due to people not stepping
> up to do the maintenance of the kernel, and the kernel alone. Having
> been one of the few people in the community that's been
On Tue, Jul 23, 2019 at 09:50:17PM +0200, Kevin Kofler wrote:
> > I would suggest that there is this nebulous thing called "the cloud"
> > that mitigates a small part of that, but I also fully understand using
> > that magical machine resource presents its own challenges.
> As the FSF puts it:
Igor Gnatenko wrote:
> From what I saw, openblas does not do any runtime detection. You
> either compile it with avx2 or not. And in runtime it will check
> whether it was enabled during compilation and use some kind of
> fallback.
If built with the DYNAMIC_ARCH option, which is the case in the
On Tue, Jul 23, 2019 at 3:48 PM Kevin Kofler wrote:
>
> What "wider aspects" would you want to consider? What implications other
> than technical matter for a technical decision such as this one?
>
This is much larger than a technical decision. There are big impacts,
as we've seen, on who can use
Josh Boyer wrote:
> I would suggest that there is this nebulous thing called "the cloud"
> that mitigates a small part of that, but I also fully understand using
> that magical machine resource presents its own challenges.
As the FSF puts it: "There is no cloud, just other people's computers."
Josh Boyer wrote:
> I think too often we focus on the technical implications (performance
> gain, etc) and sometimes don't consider wider aspects.
What "wider aspects" would you want to consider? What implications other
than technical matter for a technical decision such as this one?
On Tue, 2019-07-23 at 14:57 -0400, Josh Boyer wrote:
>
> > Also, we can't really solve the machine resources of mirrors. Well, I
> > mean, I guess we *could*, but I doubt anyone in RH is going to sign off
> > on us buying a ton of expensive storage hardware and shipping it off to
> > random
On Tue, Jul 23, 2019 at 2:37 PM Adam Williamson
wrote:
>
> On Tue, 2019-07-23 at 13:32 -0400, Josh Boyer wrote:
> > On Tue, Jul 23, 2019 at 12:39 PM Kevin Fenzi wrote:
> > > On 7/22/19 10:34 PM, Igor Gnatenko wrote:
> > > > On Tue, Jul 23, 2019 at 4:31 AM Igor Gnatenko
> > > > wrote:
> > > >
On Tue, 2019-07-23 at 13:32 -0400, Josh Boyer wrote:
> On Tue, Jul 23, 2019 at 12:39 PM Kevin Fenzi wrote:
> > On 7/22/19 10:34 PM, Igor Gnatenko wrote:
> > > On Tue, Jul 23, 2019 at 4:31 AM Igor Gnatenko
> > > wrote:
> > > Thinking about this even more, it should not be very hard thing to do:
>
On Mon, Jul 22, 2019 at 05:11:23PM -0400, Josh Boyer wrote:
> > I think I'd be more inclined to consider it if the Change was proposed
> > as a new architecture bring-up. Effectively, this would be a whole new
> > architecture that would just happen to be largely compatible with
> > x86_64.
>
>
On Tue, Jul 23, 2019 at 12:39 PM Kevin Fenzi wrote:
>
> On 7/22/19 10:34 PM, Igor Gnatenko wrote:
> > On Tue, Jul 23, 2019 at 4:31 AM Igor Gnatenko
> > wrote:
>
> > Thinking about this even more, it should not be very hard thing to do:
> >
> > * Define new architecture in RPM/libsolv (let's call
On 7/22/19 10:34 PM, Igor Gnatenko wrote:
> On Tue, Jul 23, 2019 at 4:31 AM Igor Gnatenko
> wrote:
> Thinking about this even more, it should not be very hard thing to do:
>
> * Define new architecture in RPM/libsolv (let's call it "haswell" or
> "x86_64modern")
> * Define set of capabilities
On Tue, Jul 23, 2019 at 07:52:09AM -0700, Andrew Lutomirski wrote:
> Things like CMPXCHG16B that change the set of things that can be done on
> the CPU. I could easily imagine programs that use algorithms that
> fundamentally depend on CMPXCHG16B. There is no drop-in replacement.
FWIW,
>...I think this should be retracted before it ends up being a
> phoronix article making the project look bad.
I 100% agree... but too late:
https://www.phoronix.com/scan.php?page=news_item=Fedora-31-Possible-AVX2-Require
___
devel mailing list --
On Tue, Jul 23, 2019 at 08:25:59AM -0400, Solomon Peachy wrote:
> On Tue, Jul 23, 2019 at 11:05:59AM +0200, Kevin Kofler wrote:
> > assume. And if you ask me, we should just stick to SSE2 as the baseline.
>
> Ie the status quo.
>
> > What are the big gains to be had from SSE3, SSSE3, SSE4.1,
On Mon, Jul 22, 2019 at 11:52 AM Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update
>
> == Summary ==
>
> After preliminary discussions with CPU vendors, we propose AVX2 as the
> new baseline. AVX2 support was introduced into CPUs from 2013 to
> 2015.
On Tue, Jul 23, 2019 at 11:05:59AM +0200, Kevin Kofler wrote:
> assume. And if you ask me, we should just stick to SSE2 as the baseline.
Ie the status quo.
> What are the big gains to be had from SSE3, SSSE3, SSE4.1, and SSE4.2?
Each of those individually, and from a general system library
On Tue, 23 Jul 2019 at 08:08, Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:
> Hello, Igor Gnatenko.
>
> Tue, 23 Jul 2019 07:34:06 +0200 you wrote:
>
> > * Define new architecture in RPM/libsolv (let's call it "haswell" or
> > "x86_64modern")
>
> I have a better idea: use
Hello, Igor Gnatenko.
Tue, 23 Jul 2019 07:34:06 +0200 you wrote:
> * Define new architecture in RPM/libsolv (let's call it "haswell" or
> "x86_64modern")
I have a better idea: use modules to build special AVX/SSE4 enabled
versions of some packages.
--
Sincerely,
Vitaly Zaitsev
Le 2019-07-23 12:48, Peter Robinson a écrit :
On Tue, Jul 23, 2019 at 11:31 AM Nicolas Mailhot via devel
wrote:
Le 2019-07-23 07:02, drago01 a écrit :
> Please just take back this change and come back at April first if it
> was supposed to be a joke - if not then submit again in about 10
>
On Tue, 23 Jul 2019 12:16:45 +0200
Igor Gnatenko wrote:
> On Tue, Jul 23, 2019 at 12:08 PM Kevin Kofler
> wrote:
> >
> > Igor Gnatenko wrote:
> > > 1. Lower requirement to something like SSE4 and select other CPU
> > > features which are available in most of CPUs for last decade.
> >
> > Sorry,
On Mon, Jul 22, 2019 at 8:52 PM Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update
>
> = Detailed Description ==
>
> After preliminary discussions with CPU vendors, we propose AVX2 as the
> new baseline. AVX2 support was introduced into CPUs from 2013 to
On Tue, Jul 23, 2019 at 11:31 AM Nicolas Mailhot via devel
wrote:
>
> Le 2019-07-23 07:02, drago01 a écrit :
>
> > Please just take back this change and come back at April first if it
> > was supposed to be a joke - if not then submit again in about 10
> > years.
>
> Fedora used to have the x86
On Tue, Jul 23, 2019 at 12:08 PM Kevin Kofler wrote:
>
> Igor Gnatenko wrote:
> > 1. Lower requirement to something like SSE4 and select other CPU
> > features which are available in most of CPUs for last decade.
>
> Sorry, but -1 to SSE4 too. One of my machines supports only up to SSSE3, and
>
On Tue, Jul 23, 2019 at 11:09 AM Kevin Kofler wrote:
>
> Patrik Mattsson wrote:
> > I would take the lowest denominator of features for CPUs of atleast 3
> > years of age considering how long some CPUs are being used in virtualized
> > environments and at a lot of different cloud-providers (I've
On 23/07/2019 10:40, Peter Robinson wrote:
After preliminary discussions with CPU vendors, we propose AVX2 as the
new baseline. AVX2 support was introduced into CPUs from 2013 to
2015. See
[https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX2
CPUs with AVX2].
This is not
On 7/22/19 9:51 PM, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update
Along with AVX2, it makes sense to enable certain other CPU features
which are not strictly implied by AVX2, such as CMPXCHG16B, FMA, and
earlier vector extensions such as SSE 4.2.
> > After preliminary discussions with CPU vendors, we propose AVX2 as the
> > new baseline. AVX2 support was introduced into CPUs from 2013 to
> > 2015. See
> > [https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX2
> > CPUs with AVX2].
>
> This is not what I'd call a good
Le 2019-07-23 07:02, drago01 a écrit :
Please just take back this change and come back at April first if it
was supposed to be a joke - if not then submit again in about 10
years.
Fedora used to have the x86 repo for old hardware, and the x86_64 repo
for new hardware. Now that the tech
Patrik Mattsson wrote:
> I would take the lowest denominator of features for CPUs of atleast 3
> years of age considering how long some CPUs are being used in virtualized
> environments and at a lot of different cloud-providers (I've seen 5+ year
> old CPUs in at some smaller providers).
At least
Well, that would be too much. 2011-ish hardware is still in use. But there is
some truth behind this, may be baseline should be about 2008? SSE 4.2 as a
baseline makes more sence.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe
Igor Gnatenko wrote:
> 1. Lower requirement to something like SSE4 and select other CPU
> features which are available in most of CPUs for last decade.
Sorry, but -1 to SSE4 too. One of my machines supports only up to SSSE3, and
other replies in this thread have also suggested SSSE3 as the most
On Tue, Jul 23, 2019 at 10:44 AM Nicolas Chauvet wrote:
>
> Le mar. 23 juil. 2019 à 08:30, Igor Gnatenko
> a écrit :
> >
> > On Tue, Jul 23, 2019 at 4:31 AM Igor Gnatenko
> > wrote:
> > >
> > > Hi Florian,
> > >
> > > On Mon, Jul 22, 2019 at 9:28 PM Ben Cotton wrote:
> > > >
> > > >
Hi Ben
Considering there are new CPUs being sold by Intel today that doesn't even have
AVX2 (point in case: Pentium Gold G5620), this sounds to me like a move that is
happening way too soon.
I would take the lowest denominator of features for CPUs of atleast 3 years of
age considering how long
Given the nearly only negative replies to this proposal: can we please
just officially mark it as retracted/rejected and move on?
P.S.: all my Fedora machines would no longer be able to run Fedora >=
32, effectively ending my involvement in this community :(
Ben Cotton writes:
>
On 7/22/19 8:51 PM, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update
After preliminary discussions with CPU vendors, we propose AVX2 as the
new baseline. AVX2 support was introduced into CPUs from 2013 to
2015. See
Le mar. 23 juil. 2019 à 09:38, Nicolas Chauvet a écrit :
>
> Le mar. 23 juil. 2019 à 08:30, Igor Gnatenko
> a écrit :
> >
> > On Tue, Jul 23, 2019 at 4:31 AM Igor Gnatenko
> > wrote:
> > >
> > > Hi Florian,
> > >
> > > On Mon, Jul 22, 2019 at 9:28 PM Ben Cotton wrote:
> > > >
> > > >
Le mar. 23 juil. 2019 à 08:30, Igor Gnatenko
a écrit :
>
> On Tue, Jul 23, 2019 at 4:31 AM Igor Gnatenko
> wrote:
> >
> > Hi Florian,
> >
> > On Mon, Jul 22, 2019 at 9:28 PM Ben Cotton wrote:
> > >
> > > https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update
> > >
> > > ==
On Tue, Jul 23, 2019 at 4:31 AM Igor Gnatenko
wrote:
>
> Hi Florian,
>
> On Mon, Jul 22, 2019 at 9:28 PM Ben Cotton wrote:
> >
> > https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update
> >
> > == Summary ==
> > Fedora currently uses the original K8 micro-architecture (without
>
This sounds like 'You should stop using and contributing to Fedora for
x86_64' to me.
Technically, I don't have any concern.
Practically, as a user, I only have one machine that supports AVX2
which is my laptop.
As a packager, the main machines that I use for building and testing
my packages
On Monday, July 22, 2019, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update
>
> == Summary ==
> Fedora currently uses the original K8 micro-architecture (without
> 3DNow! and other AMD-specific parts) as the baseline for its
> x86_64 architecture. This
Hi Florian,
On Mon, Jul 22, 2019 at 9:28 PM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update
>
> == Summary ==
> Fedora currently uses the original K8 micro-architecture (without
> 3DNow! and other AMD-specific parts) as the baseline for its
> x86_64
A brief survey of my hardware and less than half of it supports avx2.
I can't find a single enthusiastic endorsement for this proposal in this
thread, so far; but if this proposal ends up being adopted, I hope that this
gets announced well in advance, including a big fat banner on
Plenty has already been said here about why we should not do this (and OMFG we
should NOT do this), and I am in complete agreement.
(I have 0 machines, of 3 in my personal network, with AVX2 support. My current
desktop I only bought a year and a half ago, and it's not AVX2 capable! My
laptop
> After preliminary discussions with CPU vendors...
CPU vendors want to sell CPUs, while there are still plenty of running
Sandy/Ivy bridge expensive high-end machines running that would not be
upgradable.
Not supporting machines that are 16 years old is ok, but restricting to < 6
years (7
Once upon a time, Ben Cotton said:
> After preliminary discussions with CPU vendors, we propose AVX2 as the
> new baseline. AVX2 support was introduced into CPUs from 2013 to
> 2015. See
> [https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX2
> CPUs with AVX2].
There are
Solomon Peachy wrote:
> One sorce of data is Steam's hardware survey. Unfortunately they don't
> include AVX2, but their most recent stats show that 88.6% of their
> overall userbase has a CPU supporting AVX1. Limiting that to Linux
> users the number drops to 87.2%.
A survey among Steam's
Dominik 'Rathann' Mierzejewski wrote:
> And that's a lot of hardware. Half of my machines don't support AVX2.
> If you dropped back to SSSE3 then I wouldn't complain as that would
> just scrap my 32-bit only machines, but requiring AVX2 is definitely
> going too far.
Requiring SSSE3 would also
On Mon, Jul 22, 2019 at 02:40:29PM -0700, Joseph D. Wagner wrote:
> I may have to turn in my nerd card for not being able to pull this myself,
> but what would this list look like if the baseline was SSSE3? Just curious.
Steam claims 97.8% of their userbase has a processor supporting SSSE3
(vs
> Fedora installations on systems with CPUs which are not able to
> execute AVX2 instructions will not be able to upgrade.
So it looks like Fedora would no longer work on my laptop from 2013. I
could probably switch the laptop over to CentOS, but that would
restrict my ability to work on Fedora
On Monday, 22 July 2019 20:51:27 CEST Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update
>
> == Summary ==
> Fedora currently uses the original K8 micro-architecture (without
> 3DNow! and other AMD-specific parts) as the baseline for its
> x86_64
> On Jul 22, 2019, at 1:21 PM, Solomon Peachy wrote:
>
>> On Mon, Jul 22, 2019 at 04:11:32PM -0400, Stephen Gallagher wrote:
>> With my FESCo hat on, I can't support this action as currently stated.
>> I think I'd be more inclined to consider it if the Change was proposed
>> as a new architecture
On 2019-07-22 13:12, Felix Kaechele via devel wrote:
On 2019-07-22 2:51 p.m., Ben Cotton wrote:
After preliminary discussions with CPU vendors, we propose AVX2 as the
new baseline. AVX2 support was introduced into CPUs from 2013 to
2015. See
On Mon, Jul 22, 2019 at 2:35 PM Dominik 'Rathann' Mierzejewski
wrote:
> Anyone who wants to build a library with AVX can already do so even
> if the library doesn't support runtime detection. You just build
> twice, once with and once without and put the AVX-enabled version
> in
On Tue, 2019-07-23 at 06:01 +1000, David Airlie wrote:
> On Tue, Jul 23, 2019 at 5:58 AM Ben Cotton wrote:
> > On Mon, Jul 22, 2019 at 3:45 PM Solomon Peachy wrote:
> > > But since anectdote != data, are there any sort of deployment numbers
> > > out there that show how many Fedora deployments
Ben Cotton wrote:
> Fedora currently uses the original K8 micro-architecture (without
> 3DNow! and other AMD-specific parts) as the baseline for its
> x86_64 architecture. This baseline dates back to 2003
> and has not been updated since. As a result, performance of Fedora is
> not as good as it
Right, I was making a ha-ha-only-serious thought that perhaps there
could be a spin that is specifically highly optimized for
latest-n-greatest architectures, and if packagers want to maintain two
different versions of x64, that’d be their choice, otherwise fallback
to the ‘regular’ one. It
On Mon, Jul 22, 2019 at 4:47 PM Stephen Gallagher wrote:
>
> On Mon, Jul 22, 2019 at 2:52 PM Ben Cotton wrote:
> >
> > https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update
> >
> > == Summary ==
> > Fedora currently uses the original K8 micro-architecture (without
> > 3DNow!
On Mon, 2019-07-22 at 14:51 -0400, Ben Cotton wrote:
> After preliminary discussions with CPU vendors, we propose AVX2 as the
> new baseline. AVX2 support was introduced into CPUs from 2013 to
> 2015. See
> [https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX2
> CPUs with
On Mon, Jul 22, 2019 at 4:43 PM David Airlie wrote:
>
> On Tue, Jul 23, 2019 at 6:03 AM Josh Boyer wrote:
> >
> > On Mon, Jul 22, 2019 at 3:27 PM Ben Cotton wrote:
> > >
> > > https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update
> > >
> > > == Summary ==
> > > Fedora
On Mon, Jul 22, 2019 at 03:54:41PM -0400, Ben Cotton wrote:
> There are no stats available that could be considered defensible. At
> best, we could come up with some estimates based on the stats from
> other sources that we might assume have a similar profile as Fedora.
> I'm not sure if that data
On Mon, Jul 22, 2019 at 04:11:32PM -0400, Stephen Gallagher wrote:
> With my FESCo hat on, I can't support this action as currently stated.
> I think I'd be more inclined to consider it if the Change was proposed
> as a new architecture bring-up. Effectively, this would be a whole new
>
On Mon, Jul 22, 2019 at 03:05:15PM -0500, Ron Olson wrote:
> Perhaps as a compromise there could be a ‘regular’ 64-bit and a
> 64-bit-optimized-for-machines-made-after-2013 version?
It's not as simple as a "CPU newer than date X" cutoff -- Intel limits
AVX support to their Xeon and Core brands
On Mon, Jul 22, 2019 at 3:27 PM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update
>
>
> == Upgrade/compatibility impact ==
> Fedora installations on systems with CPUs which are not able to
> execute AVX2 instructions will not be able to upgrade.
>
I
Am 22.07.19 um 21:52 schrieb David Airlie:
>> On Mon, Jul 22, 2019 at 02:51:27PM -0400, Ben Cotton wrote:
>>> After preliminary discussions with CPU vendors, we propose AVX2 as the
>>> new baseline. AVX2 support was introduced into CPUs from 2013 to
>>> 2015. See
>>>
On 2019-07-22 2:51 p.m., Ben Cotton wrote:
After preliminary discussions with CPU vendors, we propose AVX2 as the
new baseline. AVX2 support was introduced into CPUs from 2013 to
2015. See
[https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX2
CPUs with AVX2].
Here's a
On Mon, Jul 22, 2019 at 2:52 PM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update
>
> == Summary ==
> Fedora currently uses the original K8 micro-architecture (without
> 3DNow! and other AMD-specific parts) as the baseline for its
> x86_64 architecture.
On 22/07/2019 20:42, Tom Hughes wrote:
On 22/07/2019 20:20, Tom Hughes wrote:
I will need to check but I suspect there will be a fair few
production systems at work that are missing support as well.
Out of 31 machines running F29 or F30 at work there are
only 9 with AVX2 support and only 18
* Josh Boyer [22/07/2019 15:56] :
>
> Would it be possible to include some basic instructions or a script
> for people to run on their systems to see if they are AVX2 compliant?
> That would help them assess the impact.
you can find your cpu model by running the command:
$ grep 'model name'
On Tue, Jul 23, 2019 at 6:03 AM Josh Boyer wrote:
>
> On Mon, Jul 22, 2019 at 3:27 PM Ben Cotton wrote:
> >
> > https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update
> >
> > == Summary ==
> > Fedora currently uses the original K8 micro-architecture (without
> > 3DNow! and other
> Fedora will use current CPUs more efficiently, increasing performance
> and reducing power consumption.
I hope the energy usage involved in having to buy new hardware (including
manufacturing and shipping) is taken into account. This proposed change is
incompatible with all 3 of my 64-bit
My entire involvement around Fedora is based on the fact that I was able
to use machines that had been thrown away because they were deemed
‘too old’. I have several servers and multiple laptops that run
Fedora perfectly and none of them would meet this requirement,
effectively ending any
On Tue, Jul 23, 2019 at 5:58 AM Ben Cotton wrote:
>
> On Mon, Jul 22, 2019 at 3:45 PM Solomon Peachy wrote:
> >
> > But since anectdote != data, are there any sort of deployment numbers
> > out there that show how many Fedora deployments are on AVX[2]-capable
> > hardware?
> >
> There are no
On Mon, Jul 22, 2019 at 3:27 PM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update
>
> == Summary ==
> Fedora currently uses the original K8 micro-architecture (without
> 3DNow! and other AMD-specific parts) as the baseline for its
> x86_64 architecture.
On Monday, 22 July 2019 at 20:51, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update
[...]
> == Upgrade/compatibility impact ==
> Fedora installations on systems with CPUs which are not able to
> execute AVX2 instructions will not be able to upgrade.
And
On Mon, Jul 22, 2019 at 3:45 PM Solomon Peachy wrote:
>
> But since anectdote != data, are there any sort of deployment numbers
> out there that show how many Fedora deployments are on AVX[2]-capable
> hardware?
>
There are no stats available that could be considered defensible. At
best, we could
On Tue, Jul 23, 2019 at 5:46 AM Solomon Peachy wrote:
>
> On Mon, Jul 22, 2019 at 02:51:27PM -0400, Ben Cotton wrote:
> > After preliminary discussions with CPU vendors, we propose AVX2 as the
> > new baseline. AVX2 support was introduced into CPUs from 2013 to
> > 2015. See
> >
On Mon, Jul 22, 2019 at 02:51:27PM -0400, Ben Cotton wrote:
> After preliminary discussions with CPU vendors, we propose AVX2 as the
> new baseline. AVX2 support was introduced into CPUs from 2013 to
> 2015. See
> [https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX2
> CPUs
On 22/07/2019 20:20, Tom Hughes wrote:
My firewall is brand new, built a few months ago to replace
a 32 bit machine because Fedora was deprecating that! Yet it
is a low end Celeron CPU and has no AVX2 support.
The final one is a VM from a cloud provider and even updating
to their latest
> == Upgrade/compatibility impact ==
> Fedora installations on systems with CPUs which are not able to
> execute AVX2 instructions will not be able to upgrade.
>
Time for me to switch to LinuxMint as I'm not going to be forced into hardware
updates I can't afford.
> "JLT" == Jason L Tibbitts writes:
JLT> And, let's see, I'd have to toss out five desktops (which isn't too
JLT> bad, I guess)
I was wrong. It would be 36 desktops. Being charitable requires me to
assume this was proposed without adequate consideration of just how much
hardware is
> "BC" == Ben Cotton writes:
BC> * Other developers: Other developers may have to adjust test suites
BC> which expect exact floating point results, and correct linking with
BC> libatomic. They will also have to upgrade their x86-64
BC> machines to something that can execute AVX2
On 22/07/2019 19:51, Ben Cotton wrote:
After preliminary discussions with CPU vendors, we propose AVX2 as the
new baseline. AVX2 support was introduced into CPUs from 2013 to
2015. See
[https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX2
CPUs with AVX2].
Going all the
100 matches
Mail list logo
