Skip Navigation

Jure Repinc

@ JRepin @lemmy.ml

Posts
96
Comments
19
Joined
3 yr. ago

Digital and software freedom/rights advocate from Slovenia, Europe. Also a member of the Pirate party. You can find me on Mastodon: @JRepin@mstdn.io

  • As far as I found out about this until now is that the X100 (normal cores) and A100 (AI core) are almost the same RISC-V cores, mainly only different in th RVV vector registers length spec VLEN (256 vs. 1024). The RISC-V Unprivileged specification in chapter 31.1.2. Implementation-defined Constant Parameters says this about cores with different VLENs:

    The vector extension supports writing binary code that under certain constraints will execute portably on harts with different values for the VLEN parameter, provided the harts support the required element types and instructions.

    NOTE: Code can be written that will expose differences in implementation parameters.

    NOTE: In general, thread contexts with active vector state cannot be migrated during execution between harts that have any difference in VLEN or ELEN parameters.

    So regarding this there may not be so much of a problem.

    Another probably bigger problem is that the A100 cores are not really RVA23 compliant, since they do not support Hypervisor Extension: RVH 1.0 which is required by RVA23 and is only supported on normal X100 cores. But then again usual user-level code does not use the H extension instructions. So maybe even this might not be such a problem for most user-space code.

    Anyways as things currently stand : the code only gets executed automaticaly and scheduled onto 8 X100 cores, A100 cores are ignored, even if it could also run on A100. If you are sure the code can run on A100, you must manualy move/execute them on A100 (and again they are confined to only the A100 cores).

    Probably the Linux kernel and scheduling needs to get some upgraded logic to make it able to freeely move code among X100 and A100 in the future. And again it depends on how VLEN is treated, is it fixed in the code or can it dynamically acommodate depending on the core it is currently on.

    Oh and A100 cores have support for vendor-specific SpacemiT IME (Integrated Matrix Extension) , which is based on some proposals for future RISC-V extension, but yeah nothing official yet. And looks like these are not supported on X100.

    As for SIMD. RISC-V does not have anything official yet, since the normal and more general V vector extension should be used in most (if not all common) cases to replace the SIMD instructions. There are some good cases for SIMD way of ding things but yeah RISC-V has nothing official yet, they are working on a P Packed-SIMD extension that may be available sometime in the future. As far as I could see neither X100 nor A100 support any of these P instructions.

  • There is a UEFI Requirements section in the RISC-V Boot and Runtime Services Specification (BRS) specification. But this is optional and as far as I know most SBCs don't use it. So yeah because of poor mainline Linux kernel and other components (like SBI) upstreaming by RISC-V systemproviders it is still a sad case that often you need a system specific image. So yeah I think we will need to wait until RISC-V breaks more into PC-like and server space before BRS and similar specs get used more.

  • Not yet, few are just announced. The actual ones are expected to arrive sometime in April

  • Well for x86 software still needs to be testing if some instructions are supported dynamically if they want to take adventage of the latest ones. For example you still neeed to test for different versions of AVX or even older SSE versions, since not all the x86 CPUs support everything. In 2020 something similar to RISC-V profiles was also defined for x86: microarchitectural levels. And most software just is compiled for the lowest commonly supported set of x86 instructions, in essence x86-64-v1 or x86-64-v2, depends on the software or GNU/Linux distribution. Although recently some distributions started to provide additional higher levels of packages for programs that benefit most from the use of latest x86 instructions. And then glibc HWCAPS feature enables the system to load the most optimized binary of the appliation. For example see openSUSE Tumbleweed gains optional x86-64-v3 optimization.

  • To make this easier RISC-V has profiles (the latest being RVA23), which specify a base extension set. So software can target a specific profile, and CPUs advertises which profile they support (+ possible additional extensions). Regarding naming schemes, AMD and Intel are not so clear here either, so it would not be so much different :)

  • Technology @lemmy.ml

    RISC-V takes first step toward international standardization as ISO/IEC JTC1 grants PAS Submitter status

    riscv.org /blog/risc-v-jtc1-pas-submitter/
  • RISC-V @lemmy.ml

    RISC-V takes first step toward international standardization as ISO/IEC JTC1 grants PAS Submitter status

    riscv.org /blog/risc-v-jtc1-pas-submitter/
  • I have the BPI-F3 and it comes with Bianbu distribution by default. It is based on old LTS versions of Ubuntu with some updated packages (like Mesa) and some packages optimized for the X60/K1 CPU. The problem with this CPU/SBC is that SpacemiT is bad at upstreaming the support, they do support only in their own forks of Linux kernel and other software. So upstreaming is done by volunteers and is progressing very slowly (example only for the Linux kernel), so usual distros like Debian do not have support out of the box. Also it is a problem that the K1/X60 has some Imagination PowerVR BXE-2-32 integrated graphics and this one is not supported by Mesa and only has closed binary drivers which Imagination provides to SpacemiT and they then add it into Bianbu. Also keep in mind that even this driver does not support OpenGL (the normal desktop one). Only OpenGL ES and Vulkan. So in essence this means that the compositor/windowmanager and the toolkits like Qt need to be compiled with this support which is generaly not the case in more normal distros. Sometimes they provide two sets of compiled packags, one with normal desktop OpenGL which you then have to replace with the openGL ES variants. And these are usually not so well tested in the normal daily desktop use case.

    So for daily use you more or less have to stick with Bianbu Linux on it. If you do that, I would it is quite usable, if you do not find GNOME-based desktop it has limiting as I do, since I am used to the power and plethora of features in KDE Plasma :) It is a bit slow for some more demanding tasks like video, graphics, games and stuff like that, but yeah, for simple office usecases, it is fine. So depends on what you would use it to do.

  • I would guess these are for device-tree specifications and run-time detection of what extensions some RISC-V CPU supports. Also might be some support for using these extensions in some common kernel code that is used by other parts of the kernel. But to be sure we would need to check the commits themselves.

  • My favourite Matrix client is NeoChat.

  • Well and behind it is stealing other peoples’ work (posts and comments, moderation and administration) and selling them as yours. The oldest capitalist criminal trick in the book: privatization AKA primitive accumulation AKA enclosure of the commons.

  • Those sociopaths burning the planet and pumping out all the water are completely out of touch with reality. They would rather destroy the planet for some Annoying Idiocy .

  • Crashing is the smallest problem. All that sypware, ads and artificial idiocy they are embedding in the bloated excuse of an OS is way worse than any crash. I am so glad I switched to GNU/Linux (openSUSE Tumbleweed with KDE Plasma desktop, after seeing how well gaming works on Steam Deck I also switched to GNU/Linux for gaming) and it is so so much nicer to have an OS that is fast, stable and actually respects basic human rights like privacy and freedom.

  • It would hurt this sociopath Bezos a lot more if people also canceled Amazon services en mass

  • It would hurt this sociopath Bezos a lot more if people also canceled Amazon services en mass

  • It would hurt this sociopath Bezos a lot more if people also canceled Amazon services en mass

  • These GAFAM/BigTech corporations really are in a tough and fierce competition of which one is the shittiest and most privacy-invading don't they. Ensittification overdrive mode in all of them.

  • It takes one to know one. Not much difference, if any, between Microsoft nad Google, and the rest of GAFAM/BigTech.

  • Better to use Kubuntu edition, much better desktop and less crap that is nowdays in Ubuntu.

  • I hope not. Had very bad experience with these and toxicity they enabled on Xitter and one of the main reasons why I left it for mastodon quite early. I would much more like to see if they focused on making it possible to also migrate posts when you change an instance/server.