JRepin

joined 3 years ago
MODERATOR OF
 

cross-posted from: https://lemmy.ml/post/48326251

The Commission is proposing the European Technological Sovereignty Package, marking a change in Europe's approach to its tech ecosystems.

The Commission is putting forward a multi-pronged, comprehensive strategy to achieve technological sovereignty, with initiatives that are interconnected and mutually reinforcing across each stage of the value chain, from chips, to infrastructure, to software, cloud and AI, and in synergy with past and ongoing initiatives such as AI Factories and AI Gigafactories.

This is reflected in four initiatives:

  • The Chips Act 2.0 to strengthen the semiconductor ecosystem and supply chain resilience, and boost domestic demand
  • The Cloud and AI Development Act (CADA) to unlock the potential AI and cloud, to transform our industrial ecosystems and improve societal outcomes
  • The EU Open Source Strategy to reduce dependencies across the entire technology stack
  • A Strategic Roadmap for Digitalisation and AI in Energy
 

cross-posted from: https://lemmy.ml/post/48326251

The Commission is proposing the European Technological Sovereignty Package, marking a change in Europe's approach to its tech ecosystems.

The Commission is putting forward a multi-pronged, comprehensive strategy to achieve technological sovereignty, with initiatives that are interconnected and mutually reinforcing across each stage of the value chain, from chips, to infrastructure, to software, cloud and AI, and in synergy with past and ongoing initiatives such as AI Factories and AI Gigafactories.

This is reflected in four initiatives:

  • The Chips Act 2.0 to strengthen the semiconductor ecosystem and supply chain resilience, and boost domestic demand
  • The Cloud and AI Development Act (CADA) to unlock the potential AI and cloud, to transform our industrial ecosystems and improve societal outcomes
  • The EU Open Source Strategy to reduce dependencies across the entire technology stack
  • A Strategic Roadmap for Digitalisation and AI in Energy
 

The Commission is proposing the European Technological Sovereignty Package, marking a change in Europe's approach to its tech ecosystems.

The Commission is putting forward a multi-pronged, comprehensive strategy to achieve technological sovereignty, with initiatives that are interconnected and mutually reinforcing across each stage of the value chain, from chips, to infrastructure, to software, cloud and AI, and in synergy with past and ongoing initiatives such as AI Factories and AI Gigafactories.

This is reflected in four initiatives:

  • The Chips Act 2.0 to strengthen the semiconductor ecosystem and supply chain resilience, and boost domestic demand
  • The Cloud and AI Development Act (CADA) to unlock the potential AI and cloud, to transform our industrial ecosystems and improve societal outcomes
  • The EU Open Source Strategy to reduce dependencies across the entire technology stack
  • A Strategic Roadmap for Digitalisation and AI in Energy
 

cross-posted from: https://lemmy.ml/post/48174535

AV2 is the next-generation video coding specification from the Alliance for Open Media (AOMedia). Building on the foundation of AV1, AV2 is engineered to provide superior compression efficiency, enabling high-quality video delivery at significantly lower bitrates. It is optimized for the evolving demands of streaming, broadcasting, and real-time video conferencing.

This specification serves as the definitive technical reference for AV2 implementations. It outlines the bitstream syntax, semantics, and decoding processes required to ensure full conformance.

AV2 provides enhanced support for AR/VR applications, split-screen delivery of multiple programs, improved handling of screen content, and an ability to operate over a wider visual quality range.

 

AV2 is the next-generation video coding specification from the Alliance for Open Media (AOMedia). Building on the foundation of AV1, AV2 is engineered to provide superior compression efficiency, enabling high-quality video delivery at significantly lower bitrates. It is optimized for the evolving demands of streaming, broadcasting, and real-time video conferencing.

This specification serves as the definitive technical reference for AV2 implementations. It outlines the bitstream syntax, semantics, and decoding processes required to ensure full conformance.

AV2 provides enhanced support for AR/VR applications, split-screen delivery of multiple programs, improved handling of screen content, and an ability to operate over a wider visual quality range.

 

cross-posted from: https://lemmy.ml/post/48171005

This is an abridged version of 2026 RISC-V Market Report and Ecosystem Guide by the SHDgroup, provided at no charge thanks to the support of their sponsors. An unabridged version is also available with over 200 pages and comes with a spreadsheet containing over 300 tables of detailed information. In both versions, the intention is to provide a comprehensive examination of the rapidly expanding semiconductor market, including how it is evolving alongside the concurrent emergence of RISC-V and the influence of AI. The accelerating build-out of data centers for AI inferencing and training and Large Language Models (LLMs) is having a profound impact on semiconductor revenues worldwide. This impact extends to the adoption of the RISC-V ISA in an increasing number of SoCs aimed at including some level of AI functionality in the silicon solution. These impacts also extend to the Semiconductor Intellectual Property (SIP) vendors as they look to accommodate the acceleration of the different Neural Networks being used and EDA Tool vendors as they look to infuse AI functionality into their EDA tools to aid the productivity of silicon designers.

The introduction of RISC-V has fueled extensive CPU architectural exploration, visibly impacting device revenues, unit shipments, design starts, business models and IP licensing revenues on a global basis. The pervasive integration of AI across applications is a primary catalyst in today's semiconductor market. The RISC-V architecture has notably influenced SoC designers and architects and is poised to drive a substantial share of designs, revenues, and unit shipments in the coming years.

 

cross-posted from: https://lemmy.ml/post/48171005

This is an abridged version of 2026 RISC-V Market Report and Ecosystem Guide by the SHDgroup, provided at no charge thanks to the support of their sponsors. An unabridged version is also available with over 200 pages and comes with a spreadsheet containing over 300 tables of detailed information. In both versions, the intention is to provide a comprehensive examination of the rapidly expanding semiconductor market, including how it is evolving alongside the concurrent emergence of RISC-V and the influence of AI. The accelerating build-out of data centers for AI inferencing and training and Large Language Models (LLMs) is having a profound impact on semiconductor revenues worldwide. This impact extends to the adoption of the RISC-V ISA in an increasing number of SoCs aimed at including some level of AI functionality in the silicon solution. These impacts also extend to the Semiconductor Intellectual Property (SIP) vendors as they look to accommodate the acceleration of the different Neural Networks being used and EDA Tool vendors as they look to infuse AI functionality into their EDA tools to aid the productivity of silicon designers.

The introduction of RISC-V has fueled extensive CPU architectural exploration, visibly impacting device revenues, unit shipments, design starts, business models and IP licensing revenues on a global basis. The pervasive integration of AI across applications is a primary catalyst in today's semiconductor market. The RISC-V architecture has notably influenced SoC designers and architects and is poised to drive a substantial share of designs, revenues, and unit shipments in the coming years.

 

This is an abridged version of 2026 RISC-V Market Report and Ecosystem Guide by the SHDgroup, provided at no charge thanks to the support of their sponsors. An unabridged version is also available with over 200 pages and comes with a spreadsheet containing over 300 tables of detailed information. In both versions, the intention is to provide a comprehensive examination of the rapidly expanding semiconductor market, including how it is evolving alongside the concurrent emergence of RISC-V and the influence of AI. The accelerating build-out of data centers for AI inferencing and training and Large Language Models (LLMs) is having a profound impact on semiconductor revenues worldwide. This impact extends to the adoption of the RISC-V ISA in an increasing number of SoCs aimed at including some level of AI functionality in the silicon solution. These impacts also extend to the Semiconductor Intellectual Property (SIP) vendors as they look to accommodate the acceleration of the different Neural Networks being used and EDA Tool vendors as they look to infuse AI functionality into their EDA tools to aid the productivity of silicon designers.

The introduction of RISC-V has fueled extensive CPU architectural exploration, visibly impacting device revenues, unit shipments, design starts, business models and IP licensing revenues on a global basis. The pervasive integration of AI across applications is a primary catalyst in today's semiconductor market. The RISC-V architecture has notably influenced SoC designers and architects and is poised to drive a substantial share of designs, revenues, and unit shipments in the coming years.

 

This month we received the new SpacemiT K3 board. Since its inception, felix86 wasn’t able to run on any of the out-of-order execution hardware, such as the SiFive P550 or the SOPHON SG2042. The former has no vector support, the latter has XTheadVector support. While initially there was consideration for supporting hardware without RVV 1.0 or hardware with XTheadVector, ultimately the decision was that we should instead focus on the future of RISC-V consumer hardware which will have RVV 1.0 due to it being mandatory in the RVA23 profile.

If you watched the felix86 talk at the RISC-V NA summit you might’ve seen a video of gameplay on K1 hardware. You would notice the lack of modern 3D games running on the emulator, because a lot of them would run at less than 5 frames per second. Now that we have much faster hardware, there’s more to show!

TLDW: Huge performance improvements over the K1, and RISC-V performance will only go up from here.

[–] JRepin@lemmy.ml 7 points 2 weeks ago

Nope not yet, we can still fight it. We can help others figtht it like the Linux and other people in libre/free and opensource communities are. And the best way to fight it is to boycott using any platform or product that requires it and use good alternatives that resist it.

[–] JRepin@lemmy.ml 2 points 2 weeks ago* (last edited 2 weeks ago)

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.

 

One of the RISC-V SoCs we have been most looking forward to this year is the SpacemiT K3 that features the X100 RISC-V cores that are RVA23 compliant and among the first readily available RVA23 RISC-V platform for running on the likes of Ubuntu 26.04 LTS. In this article is a preview of some very early benchmarks of the SpacemiT K3 with the new Pico-ITX single board computer offering.

The SpacemiT K3 features eight X100 RISC-V cores as well as eight ultra-wide parallel AI computing A100 cores. The X100 cores clock up to 2.4GHz and are RVA23 profile compliant and largely associated as delivering similar performance to the Arm Cortex-A76 cores. The A100 AI cores support INT4 / INT8 / FP8 / FP16 / BF16 and rated for around 60 TOPS API performance. The A100 cores are also among the few RISC-V cores so far available that support RVV 1.0 vector processing.

The SpacemiT K3 Pico-ITX is an interesting little board that pairs the K3 SoC with 10Gb networking, UFS storage, dual M.2 expansion slots, USB Type-C with power delivery and 4K DisplayPort output, and dual channel LPDDR5-6400 memory with 16GB and 32GB configurations offered.

[–] JRepin@lemmy.ml 1 points 2 weeks ago (1 children)

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.

[–] JRepin@lemmy.ml 1 points 2 weeks ago

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.

 

cross-posted from: https://lemmy.ml/post/47499847

BayLibre is proud to announce a successful collaboration with SpacemiT to enable initial functionalities of Android 16 on the SpacemiT K1 (RISC-V RVA22 + RVV 1.0) System-on-Chip (SOC). This achievement marks a significant step toward validating and accelerating Android enablement on high-end RISC-V platforms.

The main objective of this project was to validate the feasibility of porting modern Android to recent, high-performance RISC-V platforms. Furthermore, this work serves as crucial preparation for Android enablement on upcoming RISC-V profile RVA23 SOCs, as much of the effort and code will be directly reusable.

 

BayLibre is proud to announce a successful collaboration with SpacemiT to enable initial functionalities of Android 16 on the SpacemiT K1 (RISC-V RVA22 + RVV 1.0) System-on-Chip (SOC). This achievement marks a significant step toward validating and accelerating Android enablement on high-end RISC-V platforms.

The main objective of this project was to validate the feasibility of porting modern Android to recent, high-performance RISC-V platforms. Furthermore, this work serves as crucial preparation for Android enablement on upcoming RISC-V profile RVA23 SOCs, as much of the effort and code will be directly reusable.

[–] JRepin@lemmy.ml 9 points 1 year ago (2 children)

On openSUSE they have snapper snapshotting integrated into package management, so it automatically creates a snapshot before and after updates. And if something would go wrong you could easily select an old snappshot to boot from in the GRUB menu.

[–] JRepin@lemmy.ml 3 points 1 year ago (1 children)

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.

[–] JRepin@lemmy.ml 3 points 1 year ago* (last edited 1 year ago)

Oh yeah. Can't wait for this. Bad session management/restore is basically the only major thing I still miss a lot on Wayland. Hopefully Firefox and other apps will gain support for this soon (I guess all Qt/KDE apps will get support at once when they also add support to Qt and KDE Frameworks). Anyways I just opened the enhancement request for Firefox for this just hoping they will add support soon.

[–] JRepin@lemmy.ml 9 points 1 year ago (1 children)
[–] JRepin@lemmy.ml 4 points 1 year ago

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.

[–] JRepin@lemmy.ml 1 points 1 year ago

Well as they mention it, they do know.

[–] JRepin@lemmy.ml 2 points 1 year ago (1 children)

It does not break anything. Just uses C++ and builds upon it and improves it. And MOC comes in when some niceties are required that are hard to do with plain C++ (and be backwards compatible) or when more flexibility is required. If you know how to do it better, well Qt is free (as in freedom) and opensource and you can join the project and replace MOC with a better implementation. Until then it is a not so important detail and foolish to throw away entire Qt and all the numerous goodies and nice things that it brings just for this small detail.

[–] JRepin@lemmy.ml 2 points 1 year ago (3 children)

What's wrong with it? It is basically invisible and all done automatically in the background by the build system.

view more: next ›