I am really surprised with RNDA3 support. I have never seen so many issue with iGPU (APU). It started with VP9 decoder issue (e.g. just playing videos on YouTube was enough to trigger it), but that got fixed after a very long time (required a new firmware). Multiple constant [different] crashes, but you can workaround most of them by adding amdgpu.sg_display=0 to your bootargs. It's already listed in Arch Linux wiki, Gentoo wiki, etc.
Again, I was surprised by the number of firmware and driver issues since RNDA1/2/3 have been around for years now.
+1 on your initial comment. Exactly how I feel about the current situation.
MilkV Oasis with SG2380 would be the end-game for majority of developers, but they are definitely loosing money if they keep starting price at 120 USD. They don't have it frozen (they changed the SoC specification some weeks ago) thus I wouldn't be surprised to see this slip into 2025. I wouldn't be surprised if this outperforms MilkV Pioneer.
To my understanding SiFive continues to offer their selection of core IP. Anyways, I would assume any existing contract would have to be fulfilled for various legal reasons.
SG2042 itself is T-HEAD C920 design which is a mess, and might not be even called a RISC-V compliant design. We are kinda stuck it existing and being used in various chips. There are other design issues discovered IIRC (atomic might not work properly [at least on the kernel side workarounds required]; floating point failures in glibc testsuite because FP not being compliant). SG2044 is scheduled for the next year (2024). Not many details are known: 64 cores, 8 DDR controller, 3x memory bandwidth, vector v1.0 support, 2x PCIe (unknown what that means, Gen3 -> Gen4? More lanes?). The cores are unknown, but SG2038 is SiFive P670. T-HEAD has C908 that support vectors v1.0 (and solves some other issues), but that's a smaller core. Not a replacement for C910/C920.
StarFive Tech. have been upstreaming on kernel, OpenSBI and U-Boot from several weeks now. Of course this is still weeks/months away (if not more, for all the features) from landing in stable releases. Even more for distributions to pick those up.
It could be that decision to not support AVX512 was made very late in product development and thus early batches didn't have chicken bit disabled or/and fused it off.
There might be gazillions of reason why this was done.
Zba, Zbb, Zbc, Zbs (BitManip) have been approved by "Architecture Review" thus I assume they close to being ratified. Probably one of the first new extensions to be available for RISC-V.
Because it's not ratified the BitManip extensions are not listed in any RISC-V Profiles as supported (or required). Platforms specification is also not requiring it.
Note that the next Profiles will be for 2022, thus any extension ratified before that most likely will appear in a new profile (i.e. as supported, non-conflicting extension) in some set.
I am running RX 570 with PCIe + 6-pin connector for the power. These works out-of-the-box due to open source drivers. Older Nvidia cards work too, but you would need to go with older cards as you need Nouveau driver. I believe someone recently used AMD RX 6700XT, which is a bit insane.
The bottleneck here is SoC, not the GPU. With HW decoding on the GPU I can play 4K 60fps trailers on Unmatched just fine.
IIRC Allwinner has already sent some patches related to RISC-V to kernel and also suggestions to SBI specification. So far the beginning is good. Remember that they are using IP from Alibaba. Alibaba might as well work on upstreaming, etc. efforts for this (speculation).
Yesterday I decided to configure unbound on fresh Fedora 28 Beta install and configure it to use DNS-over-TLS to Cloudflare and Quad9. unbound runs as local recursive resolver. Within a laptop it's decrypted, but all outside communications are over TLS (checked with wireshark). The 1st query for unknown domain is slow, ~300-1000 ms, but afterwards it always report 0ms. unbound in background should automatically update those record in the cache. So far works with no problems noticed.
IIUC, a limited number of people from kernel community knew about this and NDAs didn't exactly allow all the parties work together. The first solutions/mitigations exist (might not be nice), but now embargo is lifter and the communities (incl. companies) can work on better solutions together.
ARM whitepaper states that conditional selection/conditional move is enough on most ARM implementations. If it's not the case then the new CSDB solves the problem. On older CPUs it's still a NOP.
Cortex A53 and A55 (in-order designs) are not vulnerable to any variant. ARM Ltd. provide details for all of their designs (it's a bit like Swiss cheese, each core is vulnerable to different variants). Thus low/mid-tiers and half of cores in big.LITTLE configuration are safe. The worst is latest gen, Cortex A75, which is vulnerable to all of variants (incl. Meltdown).
ABIs have changed after we did this. We get the first long-term stable ABI with 4.15 kernel and glibc 2.27 (hopefully). At that point Fedora, Debian, and others can reboot efforts.
Again, I was surprised by the number of firmware and driver issues since RNDA1/2/3 have been around for years now.