On 4/19/23 00:26, Benson Muite wrote:
Probably each hardware vendor will need to become more involved in
creating an RPM distribution for their use case and providing hardware
for test builds. A single monolithic Fedora will not work. Having a
subset of base packages would be very
On 4/19/23 07:46, Florian Weimer wrote:
* Jeff Law:
Rather than trying to track all the individual extensions and
combinations thereof, I would suggest focusing on RVI defined
profiles. Essentially they provide a set of mandatory features the
architecture must support (to be compliant with
On Wed, Apr 19, 2023 at 09:26:55AM +0300, Benson Muite wrote:
> Probably each hardware vendor will need to become more involved in
> creating an RPM distribution for their use case and providing hardware
> for test builds. A single monolithic Fedora will not work. Having a
> subset of base
* Jeff Law:
> Rather than trying to track all the individual extensions and
> combinations thereof, I would suggest focusing on RVI defined
> profiles. Essentially they provide a set of mandatory features the
> architecture must support (to be compliant with the profile).
Do at least some of
On 4/15/23 19:56, Kevin Fenzi wrote:
> On Sat, Apr 15, 2023 at 08:38:47AM -0600, Jeff Law wrote:
>>
>>
>> On 4/15/23 00:10, David Abdurachmanov wrote:
>>
>>
>>>
>>> We have to support SCBs as-is. We even have 64-core OoO (and even
>>> dual-socket 128-core) systems coming that are still RVA20 (what
https://github.com/rpm-software-management/rpm/releases/tag/rpm-4.19.0-alpha
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://github.com/rpm-software-management/rpm/releases/tag/rpm-4.19.0-alphaf
5 days ago.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
On Sat, Apr 15, 2023 at 08:38:47AM -0600, Jeff Law wrote:
>
>
> On 4/15/23 00:10, David Abdurachmanov wrote:
>
>
> >
> > We have to support SCBs as-is. We even have 64-core OoO (and even
> > dual-socket 128-core) systems coming that are still RVA20 (what I call
> > "a large scale SBC trying
On 4/15/23 00:25, David Abdurachmanov wrote:
On Sat, Apr 15, 2023 at 7:08 AM Jeff Law wrote:
On 4/14/23 20:14, Neal Gompa wrote:
We should not screw up with RISC-V in Fedora like RHEL did with ARM.
Yes, I'm saying RHEL's ARM strategy was a mistake, and still is, to
some degree. We
On 4/15/23 00:10, David Abdurachmanov wrote:
We have to support SCBs as-is. We even have 64-core OoO (and even
dual-socket 128-core) systems coming that are still RVA20 (what I call
"a large scale SBC trying to be a server").
I think elsewhere you suggested treating the profile as the
Once upon a time, David Abdurachmanov said:
> I would love to avoid supporting SBCs, especially as some of them are
> really not suitable for feature rich Linux distributions.
For me, my only interest in the foreseeable future for RISC-V would be
SBCs, as an alternative to ARM (e.g. Raspberry
On Sat, Apr 15, 2023 at 7:08 AM Jeff Law wrote:
>
>
>
> On 4/14/23 20:14, Neal Gompa wrote:
>
> >>
> >
> > We should not screw up with RISC-V in Fedora like RHEL did with ARM.
> > Yes, I'm saying RHEL's ARM strategy was a mistake, and still is, to
> > some degree. We see aspects of this being
On Sat, Apr 15, 2023 at 5:30 AM Neal Gompa wrote:
>
> On Fri, Apr 14, 2023 at 10:01 PM Jeff Law wrote:
> >
> >
> >
> > On 4/12/23 10:08, przemek klosowski via devel wrote:
> > >>
> > >> That may rule out certain processors, but it ultimately provides a
> > >> higher performing baseline
On Sat, Apr 15, 2023 at 5:01 AM Jeff Law wrote:
>
>
>
> On 4/12/23 10:08, przemek klosowski via devel wrote:
> >>
> >> That may rule out certain processors, but it ultimately provides a
> >> higher performing baseline architecture for systems that are
> >> (hopefully) going to be good performing
On Sat, Apr 15, 2023 at 4:49 AM Jeff Law wrote:
>
>
>
> On 4/12/23 10:57, David Abdurachmanov wrote:
>
> >
> > We have been focusing and building for RV64GC, which is kinda
> > represented by the RVA20 profile. RVA20 is considered a major profile,
> > but it significantly lacks modern ISA
On 4/14/23 20:14, Neal Gompa wrote:
We should not screw up with RISC-V in Fedora like RHEL did with ARM.
Yes, I'm saying RHEL's ARM strategy was a mistake, and still is, to
some degree. We see aspects of this being walked back now as the
ecosystem didn't go the way RHEL ARM folks hoped,
On Fri, Apr 14, 2023 at 10:01 PM Jeff Law wrote:
>
>
>
> On 4/12/23 10:08, przemek klosowski via devel wrote:
> >>
> >> That may rule out certain processors, but it ultimately provides a
> >> higher performing baseline architecture for systems that are
> >> (hopefully) going to be good performing
On 4/12/23 10:08, przemek klosowski via devel wrote:
That may rule out certain processors, but it ultimately provides a
higher performing baseline architecture for systems that are
(hopefully) going to be good performing parts rather than embedded
focused parts.
Yes, good point, but
On 4/12/23 10:57, David Abdurachmanov wrote:
We have been focusing and building for RV64GC, which is kinda
represented by the RVA20 profile. RVA20 is considered a major profile,
but it significantly lacks modern ISA extensions. There is also RVA22,
which is considered a "minor" profile. The
On Wed, Apr 12, 2023 at 7:08 PM przemek klosowski via devel
wrote:
>
>
> On 4/11/23 22:08, Jeff Law wrote:
> > On 4/11/23 19:14, przemek klosowski via devel wrote:
> >> The situation in the RISC-V universe is even more complicated because
> >> of all the extensions
> >>
> >> ...
> >> Whatever
On 4/11/23 22:08, Jeff Law wrote:
On 4/11/23 19:14, przemek klosowski via devel wrote:
The situation in the RISC-V universe is even more complicated because
of all the extensions
...
Whatever standard scheme Fedora uses for x86 will hopefully be very
useful for RiSC-V era that is apparently
On 4/11/23 19:14, przemek klosowski via devel wrote:
On 4/4/23 10:28, Dan Čermák wrote:
Chris Adams writes:
Yeah, it'd be back to the i386/i586/i686 days... which was a bit of a
PITA sometimes. But cramming multiple architectures of core libraries
into a single RPM would be bad for disk
On 4/4/23 10:28, Dan Čermák wrote:
Chris Adams writes:
Yeah, it'd be back to the i386/i586/i686 days... which was a bit of a
PITA sometimes. But cramming multiple architectures of core libraries
into a single RPM would be bad for disk space, image size, downloads,
etc.
But something that
On Tue, Apr 4, 2023 at 10:32 AM Vitaly Zaitsev via devel
wrote:
>
> On 04/04/2023 15:15, Neal Gompa wrote:
> > But overall? I don't think so.
>
> Web browsers, game engines, audio/video editing software.
>
Portions of web browsers and game engines (multimedia bits and physics
libraries, which we
On 04/04/2023 15:15, Neal Gompa wrote:
But overall? I don't think so.
Web browsers, game engines, audio/video editing software.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To
Chris Adams writes:
> Once upon a time, Zbigniew Jędrzejewski-Szmek said:
>> On Tue, Apr 04, 2023 at 11:17:50AM +0200, Jakub Jelinek wrote:
>> > Why a subrpm? Should be possible to just arrange for one src.rpm to
>> > build the library twice and install the x86-64-v3 into
>> >
On Tue, Apr 04, 2023 at 09:05:43AM -0400, Stephen Smoogen wrote:
> On Tue, 4 Apr 2023 at 08:52, Zbigniew Jędrzejewski-Szmek
> wrote:
>
> > On Tue, Apr 04, 2023 at 11:17:50AM +0200, Jakub Jelinek wrote:
> > > On Tue, Apr 04, 2023 at 07:37:59AM +, Zbigniew Jędrzejewski-Szmek
> > wrote:
> > > >
On Tue, Apr 4, 2023 at 8:35 AM Vitaly Zaitsev via devel
wrote:
>
> On 04/04/2023 11:17, Neal Gompa wrote:
> > It seems that moving to -O3 would provide more gains than x86_64-v3.
>
> AVX2 can significantly boost the performance of modern processors in
> SIMD operations.
>
Yes, provided they are
Once upon a time, Zbigniew Jędrzejewski-Szmek said:
> On Tue, Apr 04, 2023 at 11:17:50AM +0200, Jakub Jelinek wrote:
> > Why a subrpm? Should be possible to just arrange for one src.rpm to
> > build the library twice and install the x86-64-v3 into
> > /usr/lib64/glibc-hwcaps/x86-64-v3/
> >
On Tue, 4 Apr 2023 at 08:52, Zbigniew Jędrzejewski-Szmek
wrote:
> On Tue, Apr 04, 2023 at 11:17:50AM +0200, Jakub Jelinek wrote:
> > On Tue, Apr 04, 2023 at 07:37:59AM +, Zbigniew Jędrzejewski-Szmek
> wrote:
> > > On Sun, Apr 02, 2023 at 09:54:04PM +0200, Dan Čermák wrote:
> > > > The only
On Tue, Apr 04, 2023 at 11:17:50AM +0200, Jakub Jelinek wrote:
> On Tue, Apr 04, 2023 at 07:37:59AM +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Sun, Apr 02, 2023 at 09:54:04PM +0200, Dan Čermák wrote:
> > > The only benchmark that *I* am aware of is this one done by Martin
> > > Jambor:
On 04/04/2023 11:17, Neal Gompa wrote:
It seems that moving to -O3 would provide more gains than x86_64-v3.
AVX2 can significantly boost the performance of modern processors in
SIMD operations.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
On Tue, 4 Apr 2023 at 05:18, Neal Gompa wrote:
> On Tue, Apr 4, 2023 at 3:38 AM Zbigniew Jędrzejewski-Szmek
> wrote:
> >
> > On Sun, Apr 02, 2023 at 09:54:04PM +0200, Dan Čermák wrote:
> > > The only benchmark that *I* am aware of is this one done by Martin
> > > Jambor:
V Tue, Apr 04, 2023 at 07:37:59AM +, Zbigniew Jędrzejewski-Szmek napsal(a):
> Yeah, I think that's the way to go. I think we should identify 100
> shared libraries which would be positively impacted by x86-64-v3
> and provide a -v3 subrpm for them. This would be a nice feature for
> F40.
>
On Tue, Apr 4, 2023 at 3:38 AM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Sun, Apr 02, 2023 at 09:54:04PM +0200, Dan Čermák wrote:
> > The only benchmark that *I* am aware of is this one done by Martin
> > Jambor: https://jamborm.github.io/spec-2022-07-29-levels/
>
> This is very … underwhelming.
On Tue, Apr 04, 2023 at 07:37:59AM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Sun, Apr 02, 2023 at 09:54:04PM +0200, Dan Čermák wrote:
> > The only benchmark that *I* am aware of is this one done by Martin
> > Jambor: https://jamborm.github.io/spec-2022-07-29-levels/
>
> This is very …
On Tue, Apr 04, 2023 at 11:02:53AM +0200, Florian Weimer wrote:
> * Zbigniew Jędrzejewski-Szmek:
>
> > And -Ofast is not something that can be enabled as a default build flag,
> > because it leads to surprising and unpredictable behaviour in some
> > cases. (*)
>
> I assume (*) refers to the the
* Zbigniew Jędrzejewski-Szmek:
> And -Ofast is not something that can be enabled as a default build flag,
> because it leads to surprising and unpredictable behaviour in some
> cases. (*)
I assume (*) refers to the the strange-action-at-distance issue. It was
recently fixed in GCC:
On Sun, Apr 02, 2023 at 09:54:04PM +0200, Dan Čermák wrote:
> The only benchmark that *I* am aware of is this one done by Martin
> Jambor: https://jamborm.github.io/spec-2022-07-29-levels/
This is very … underwhelming. x86-64-v2 is essentially identical to x86-64-v1.
x86-64-v3 is better. It even
On 4/3/23 08:04, Florian Weimer wrote:
> * Florian Festi:
>
>> On 3/31/23 15:40, Stephen Gallagher wrote:
>>> On Thu, Mar 30, 2023 at 3:42 PM Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/RPM-4.19
>>>
== Detailed Description ==
RPM 4.19 contains various
Il 02/04/23 18:42, Fabio Valentini ha scritto:
> On Sun, Apr 2, 2023 at 5:37 PM Mattia Verga via devel
> wrote:
>> Il 31/03/23 17:27, Florian Festi ha scritto:
>>> On 3/31/23 15:40, Stephen Gallagher wrote:
On Thu, Mar 30, 2023 at 3:42 PM Ben Cotton wrote:
>
* Florian Festi:
> On 3/31/23 15:40, Stephen Gallagher wrote:
>> On Thu, Mar 30, 2023 at 3:42 PM Ben Cotton wrote:
>>>
>>> https://fedoraproject.org/wiki/Changes/RPM-4.19
>>
>>> == Detailed Description ==
>>> RPM 4.19 contains various improvements over previous versions. Many of
>>> them are
Hi,
Mattia Verga via devel writes:
> Il 31/03/23 17:27, Florian Festi ha scritto:
>> On 3/31/23 15:40, Stephen Gallagher wrote:
>>> On Thu, Mar 30, 2023 at 3:42 PM Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/RPM-4.19
== Detailed Description ==
RPM 4.19 contains
On 02/04/2023 17:36, Mattia Verga via devel wrote:
Is there anyone who could provide some benchmarks to see if there are
significant performance improvements about using v2/v3/v3 versus plain
x86_64?
AVX2 can bring a huge performance boost.
--
Sincerely,
Vitaly Zaitsev
On Sun, Apr 2, 2023 at 5:37 PM Mattia Verga via devel
wrote:
>
> Il 31/03/23 17:27, Florian Festi ha scritto:
> > On 3/31/23 15:40, Stephen Gallagher wrote:
> >> On Thu, Mar 30, 2023 at 3:42 PM Ben Cotton wrote:
> >>> https://fedoraproject.org/wiki/Changes/RPM-4.19
> >>> == Detailed Description
Il 31/03/23 17:27, Florian Festi ha scritto:
> On 3/31/23 15:40, Stephen Gallagher wrote:
>> On Thu, Mar 30, 2023 at 3:42 PM Ben Cotton wrote:
>>> https://fedoraproject.org/wiki/Changes/RPM-4.19
>>> == Detailed Description ==
>>> RPM 4.19 contains various improvements over previous versions. Many
> https://fedoraproject.org/wiki/Changes/RPM-4.19
>
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal will only be implemented if approved
> by the Fedora Engineering Steering
On 3/31/23 15:40, Stephen Gallagher wrote:
> On Thu, Mar 30, 2023 at 3:42 PM Ben Cotton wrote:
>>
>> https://fedoraproject.org/wiki/Changes/RPM-4.19
>
>> == Detailed Description ==
>> RPM 4.19 contains various improvements over previous versions. Many of
>> them are internal in nature such as
Dne 31. 03. 23 v 15:40 Stephen Gallagher napsal(a):
* Creating User and Groups from sysusers.d files including Provides
and Requires or Recommends
I may have cried a little bit in joy here. This is huge!
Yes! Huge thanks for this.
Miroslav
___
On Thu, Mar 30, 2023 at 3:42 PM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/RPM-4.19
> == Detailed Description ==
> RPM 4.19 contains various improvements over previous versions. Many of
> them are internal in nature such as moving from automake to cmake,
> improvements to the
https://fedoraproject.org/wiki/Changes/RPM-4.19
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
https://fedoraproject.org/wiki/Changes/RPM-4.19
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
52 matches
Mail list logo
