[HN Gopher] riscv64 is now an official Debian architecture (rebo...
___________________________________________________________________
riscv64 is now an official Debian architecture (rebootstrap in
progress)
Author : pabs3
Score : 106 points
Date : 2023-07-23 12:25 UTC (10 hours ago)
(HTM) web link (lists.debian.org)
(TXT) w3m dump (lists.debian.org)
| rwmj wrote:
| Why are they "rebootstapping"? Or does that mean they're just
| recompiling all the .debs again, but using the existing
| environment? (For context I've bootstrapped Fedora on riscv64
| from scratch three times, and I wouldn't be keen to ever have to
| do it again.)
| snvzz wrote:
| Debian unofficial ports are built separately.
|
| As RISC-V is now official, it needs to be rebuilt with the
| infrastructure that builds all official architectures.
|
| There should be no issues, as the unofficial port is already
| building over 95% of the Debian package library. Note that
| Debian is the biggest distribution, so this is no small feat.
|
| In a couple weeks, it should all be sorted, with the official
| port built to the same level the unofficial port was.
| rwmj wrote:
| Sure, we also build most of Fedora on a separate build system
| (http://fedora.riscv.rocks/koji/) so it's a pretty similar
| situation.
| dima55 wrote:
| "rebootstrap" is the tool used today to bring up a new
| architecture. My understanding is that most of the process is
| now automated.
| beebmam wrote:
| Where would I go about buying a serious risc-v PC? So far, all
| I've seen are either tiny devices without much computation power,
| or emulation support.
|
| Is risc-v a legitimate platform for serious computation or is it
| targeted at embedded devices?
| snvzz wrote:
| If you want to play with running Linux on RISC-V today or doing
| any porting work, VisionFive2 is where it's at.
|
| They are serious about upstream support[0].
|
| 0. https://rvspace.org/en/project/JH7110_Upstream_Plan
| saagarjha wrote:
| There are people working to make server-level chips for it but
| none of them are really quite ready yet.
| snvzz wrote:
| Ventana Veyron is due before year end.
|
| Tenstorrent Ascalon (led by who was Apple M1 lead architect)
| promises competitive performance with projected AMD Zen5, and
| is due 2024 (same as Zen5).
| imtringued wrote:
| ARM had decades to get into the server market and they are
| still struggling. Sure AWS' server instances are reasonably
| good but competitive RISC-V server hardware will be coming
| out over the next five years and then it is over for ARM.
|
| I personally thought that Microsoft was going to abandon
| x86 for ARM in 2017 because it means they can lock the
| platform down even further with applications only being
| installable from their proprietary store and the bootloader
| being locked to windows only. Six years later nothing
| happened. ARM is on its deathbed.
| snvzz wrote:
| re: AWS, I wouldn't be surprised if the next iteration of
| graviton is RISC-V, or the one after.
| my123 wrote:
| Delusion.
| yjftsjthsd-h wrote:
| Possibly, but it'd be nice if you explained why. If AWS
| can get semi custom chips for one architecture, why not
| another?
| my123 wrote:
| RISC-V is not remotely anywhere near ready for such a
| thing. On my side we really don't understand this push
| beyond embedded at all.
| IshKebab wrote:
| I think there are a few reasons why there's no point currently:
|
| * There aren't really any available for a reasonable price.
|
| * A lot of the desktop related stuff is still in the process of
| being specified and ratified. If you buy something now it will
| probably use a load of ad-hoc features especially for booting.
|
| * It doesn't _really_ make any difference to running software,
| unless you are writing assembly. If you just want to play
| around with RISC-V assembly an emulator or cheap embedded
| hardware is a lot better option.
| panick21_ wrote:
| RISC-V by design and be ambition is for everything, serious
| compute and embedded. Its just that its far easier to release
| embedded chips and that standard for that was ready far
| earlier.
|
| Serious compute simply takes far longer in terms of product
| cycle and the relevant standard came far later.
|
| A lot of use for RISC-V is also not in places that is target at
| end consumer devices.
|
| There is not much yet in terms of RISC-V PC? The HiFive Pro
| P550 should be coming out at some point. Or the Unmatched
| currently.
|
| https://www.sifive.com/boards/hifive-unmatched
|
| https://www.sifive.com/boards/hifive-pro-p550
|
| Companies working on high performance RISC-V are: Esperanto,
| SiFive, Ventana Micro Systems and Tenstorrent.
| snvzz wrote:
| And Rivos.
| camel-cdr wrote:
| https://milkv.io/pioneer seems to be what you are looking for,
| but I'd only recommend it for developers who are working on
| getting things like gpu drivers ported.
|
| For most development smaller SBCs are enough, and I'd recommend
| waiting for RVA22/23 profile supporting hardware before
| spending a lot of money, because most current chips use the non
| standard vector isa and don't support all profile extensions,
| because they where created before everything was ratified.
| rwmj wrote:
| At least 4 companies are working on server-class chips,
| targeting "Xeon-like" performance. Of course without actual
| hardware to test you should take those claims with a grain of
| salt for the moment.
|
| If you want a cheap, low-end single board computer you can use
| right now, then I'd go for either the Vision Five 2 or the
| Sipeed Lichee Pi 4A. Performance won't be that great, but it'll
| run Fedora, Debian, Ubuntu or Yocto distros pretty much out of
| the box. I'm working on a Hifive Unmatched vs VF2 vs Sipeed vs
| Raspberry Pi 4B performance comparison right now, which will
| appear on https://rwmj.wordpress.com
| jeffbee wrote:
| It's interesting that the project officially supports riscv64 but
| other architectures in a similar ecosystem niche, but vastly
| larger installed base, like SH4, have been unofficial ports for
| decades. Perhaps this is a good comparative example of how to
| effectively engage the community, or fail to.
| ncts wrote:
| Number of active maintainers is a key factor. Compare to this:
| https://lists.debian.org/debian-mips/2023/07/msg00012.html
| lambda wrote:
| Where are you getting the "vastly larger installed base"? On
| popcon riscv64 is a lot higher than sh4:
| https://popcon.debian.org/stat/submission-1year.png
|
| There may be more hardware out there with SH4 processors, like
| some NAS boxes, but are they using or contributing to Debian?
| And when I look at a list of hardware with SuperH processors,
| half of the links are broken links:
| https://elinux.org/Processors#SuperH
|
| SuperH seems like a niche architecture mostly supported by a
| single vendor and available in a few devices mostly in the
| Japanese market, without a huge amount of use in the Debian
| community.
|
| RISC-V may not yet have as much extant hardware available, but
| there's tons of active development, and the open licensing
| model means that a lot of companies are working on RISC-V
| chips, which will then flow into hardware.
| jeffbee wrote:
| I'm not suggesting that SuperH would become an official port
| _today_ when it is clearly dead. But the question is why it
| was never an official port even when it was in its prime. As
| for the installed base, it is absolutely terrifyingly large.
| They had a lot of wins in automotive, and popular consumer
| products like Sonos are based on it, or were for the first
| decade of that product line, and those products also run
| Linux.
| lambda wrote:
| Even in its prime, it simply didn't have enough interest
| from Debian developers for maintaining an official port.
|
| With each release there are roll-call emails to help judge
| whether a port has sufficient maintenance to be included in
| the official release, and I generally see a single
| developer for SuperH/SH4: https://lists.debian.org/debian-
| devel/2013/10/msg00134.html
|
| There are a few more developers listed on the qualification
| page, but they don't seem to be responding to the roll-call
| messages: https://wiki.debian.org/ArchiveQualification/sh4
|
| Debian doesn't sit down and do market research on amount of
| hardware shipped, and then allocate developers and
| resources based on that; they base whether there's an
| official port on whether there are already enough
| developers and infrastructure to maintain it, as builds
| failing on that port can block work on packages.
|
| And besides the developers, the SH4 port had infrastructure
| issues, such as taking 6 days to build GCC:
| https://lists.debian.org/debian-
| release/2011/04/msg00173.htm...
|
| So the answer to "why wasn't SH4 an official port" is
| likely "there simply weren't enough developers and
| infrastructure for supporting it."
| orra wrote:
| I can't speak for why SH4 was always unofficial, but from a
| vibes perspective today, RISC-V feels like an architecture on
| the up. That probably helps attract more developers, and
| ultimately it takes people to do the work.
| zX41ZdbW wrote:
| We have recently added official builds of ClickHouse for
| RISCV-64: https://github.com/ClickHouse/ClickHouse/pull/31398
|
| Although the support existed for several years, it was not
| automated until recently.
| kosolam wrote:
| Sounds exciting. I haven't figured yet how I can make use of
| riscv but my hands are scratching and I'm an avid debian user.
| Anyone here does interesting hobby projects with riscv hardware?
| stevefan1999 wrote:
| What about SIMD support? Most software (like ffmpeg) clearly
| aren't having nor is going to use the current SIMD specification
| for rv64
| photonbeam wrote:
| riscv provides a vector unit instead of a traditional simd
| cbm-vic-20 wrote:
| I thought I had read somewhere that the Packed SIMD (P)
| extension was still going to be developed for implementations
| that don't need the full-blown Vector (V) extension, for
| example, embedded processors for digital signal processing.
|
| https://github.com/riscv/riscv-p-spec/
| https://github.com/riscv/riscv-v-spec/
| snvzz wrote:
| The packed SIMD effort hasn't moved in years, as there's no
| interest (commercial or otherwise).
|
| This is in no small part due to the ratified V extension
| scaling well in both directions (smaller and larger
| designs).
| photonbeam wrote:
| There dosent seem to be a lot of demand for it
|
| Debian would target typical linux application usage
| dzaima wrote:
| The P extension is quite "small" though - it works in the
| regular 32/64-bit x1-x31 GPRs, which is also pretty far
| from traditional SIMD.
| camel-cdr wrote:
| The packed simd extension isn't ratified and mostly aimed at
| embedded processors that need to do digital signal processing.
|
| The vector extension (rvv) is what's important for desktop and
| server chips, and it is already ratified.
|
| ffmpeg for example already has some things ported to rvv [0],
| and many projects are already working on support.
|
| The problem is that there currently isn't any consumer hardware
| that supports the ratified vector extension. Sipeed announced
| [1] that they are working on a RVA22+V soc based on the C908
| chip, this will likely be the first one developers can get
| their hands on.
|
| [0]
| https://git.ffmpeg.org/gitweb/ffmpeg.git/tree/HEAD:/libavcod...
|
| [1] https://twitter.com/SipeedIO/status/1654055669774036993
| leonheld wrote:
| This is the real issue with adopting new architectures, imho.
| So many packages claim to support arm, for example, whilst not
| enabling the proper optimisation flags, rendering it unusable.
| A loooot of work we take for granted has been put to optimize
| things for x86.
| dzaima wrote:
| rvv1.0 is frozen, and ffmpeg does contain some usage of it:
| https://git.ffmpeg.org/gitweb/ffmpeg.git/tree/HEAD:/libavcod...
| arp242 wrote:
| To contextualize this - because I had no idea if those 13
| files constituted "a lot", "very little", or anything in
| between - here's a comparison of amount of asm code for each
| platform: Files Lines
| Blanks Comments Code aarch64 35
| 24,703 1,999 0 22,704 alpha
| 3 471 57 0 414 arm
| 69 30,600 1,975 0 28,625
| loongarch 6 6,531 485 0
| 6,046 ppc 2 605 50
| 0 555 riscv 13 1,284 71
| 0 1,213 x86 97 48,669 4,260
| 4418 39,991
|
| This is a very rough comparison and doesn't take in to
| account the C code for every platform (which seems to scale
| roughly but not exactly the same), programming style,
| architecture differences, etc. but it should be roughly
| accurate.
| camel-cdr wrote:
| There are also these h264 patches floating around, but I
| don't think they have been fully merged yet:
| https://ffmpeg.org/pipermail/ffmpeg-
| devel/2023-May/309386.ht...
___________________________________________________________________
(page generated 2023-07-23 23:02 UTC)