davidlt

This isn't a problem. See article [EN][0]. Simply put we are significantly below the cap. If somehow we would manage to hit the cap it definitely should be an alarm for investigation. I feel more folks are unhappy because EU was divided into two parts with this.

[0] https://www.lrt.lt/en/news-in-english/19/2461209/will-lithua...

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.

Upstreasming status: https://rvspace.org/en/new-page/JH7110_Upstream_Plan

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.

There are Profiles specs and Platforms specs, that will be regularly updated. This means software has a fixed target on which it can depend.

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.

For the price point they are going it's plenty enough. That's also enough to boot Linux distributions in headless mode.

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).

06:34PM EDT - Q: plans to support RVV 1.0? A: 0.7.1 for now - when we designed, it was still at that level. We are following and working on that yes.

From https://www.anandtech.com/show/15991/hot-chips-2020-live-blo...

0.7.1 and 1.0 will not be compatible IIRC thus Linux distribution most likely will not support RVV on this.

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.

We are working on Fedora RISC-V.

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.

On ARM (A64, A32, T32) we get CSDB barrier, but it's a hint instruction instead of going via MSR registers.

From whitepaper CSDB is 1101_0101_0000_0011_0010_0010_100_11111

Here some snippets from ARM manuals:

HINT instruction:

1101 0101 0000 0011 0010 0010 100 11111 CRm = 0010 op2 = 100

Some encodings described here are not allocated in this revision of the architecture, and behave as NOPs. (This is important)

Hints 18 to 23 variant Applies when CRm == 0010 && op2 != 00x. HINT #<imm>

Hint is encoded in CRm:op2 pair, existing similar:

0010:000 ESB // Error Synchronization Barrier 0010:001 PSB CSYNC // Profiling Synchronization Barrier

Thus in assembler this is written:

hint #0x14

Which is a NOP if SOC does not understand this hint. It's being used here: http://lkml.iu.edu/hypermail/linux/kernel/1801.0/04191.html

and also here: https://github.com/ARM-software/speculation-barrier/blob/mas... (which is being upstreamed to compilers in cross-platform generic form IIRC)

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.

X-Gene disables branch prediction: http://lkml.iu.edu/hypermail/linux/kernel/1801.2/06482.html

ThunderX2 branch prediction hardening: https://patchwork.kernel.org/patch/10151975/

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).

It's all in ARM Ltd. report and whitepaper.

Stable ABI. We have done ~Fedora 25 in late 2016 - https://fedoraproject.org/wiki/Architectures/RISC-V and you can even boot that in your browser - https://bellard.org/jslinux/

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.