# arm Tech Symposia 2022 @ Taipei

###### tags: `arm`

## [Unleashing Gaming Performance with the Arm Immortalis-G715 GPU](https://techsymposia.arm.com/tw/sessions/Track_C1)

arm annouces the new GPU Immortalis-G715, which has hardware-based **Ray Tracing** and **Varaible Rate Shading** support. 

This comes from the demand "Gaming is 'Mobile first'". 

More detail of the improvment: 

### Ray Tracing

Compare between disabled and enabled ray tracing:
* Disabled ray tracing - The color is flatter 
* Enabled ray tracing - We can see the reflected light from the waxed floor 

Gaming engine have to invoke the ray tracing feature, of course.

There two important instruction provided by Ray Tracing Uit (RTU): `RBOX_UNIT (RT_RAY_BOX)` and `RTRI_UNIT (RT_RAY_TRI)` 

## Variable Rate Shading (VRS)

We understand that down sampling rate can reduce the workload. 

What if down sampling the background, but keep the original sampling rate for foreground objects, then merge the two pictures when do shading. This reduces some workload, saves energy, but has good enough gaming experience for visualization.

## [STM32 Accelerates the Creation of Smart Devices](https://techsymposia.arm.com/tw/sessions/Track_C2)

ST suggests arm Cortex-M7 for HMI things. 

### Low Power Background Autonomous Mode (LPBAM)

STM32U5 has Low Power Background Autonomous Mode (LPBAM). 
The arm core can keep sleep and be woken up by the notification from DMA complete.

The core can be woken up by multiple peripherals' DMA.
Especially the audio digitial filter, it reminds me the history we met on some laptops before. The smart DMIC cases, for example the Alexa voice event case. But, this one is the Cortex-M core, not a common CPU.

From the overall view: 

With low power mode, it does save a lot of power 

## [Automotive Products and Solutions for the Software Defined Vehicle](https://techsymposia.arm.com/tw/sessions/Track_A3)

This talk is from top view.

People are thinking that re-use the methodology on vehicle from the Smartphone and Datacenter:
* Deployability
* Software Updates
* Security
* Development
* CI/CD
* Functional Safety
* Real-time response

Can we reduce the development time frame? For example, software and hardware design can start and develope parallelly. 

arm introduces the project [Scalable Open Architecture For Embedded Edge (SOAFEE)](https://soafee.io/) 

From the Cloud Native Architecture:
* CI/CD is common.
* The applications / services run in containers.
* The containersrun on an OS.
* The OS runs on a **silicon / board** with [SystemReady](https://www.arm.com/en/architecture/system-architectures/systemready-certification-program), or in a **virtual machine**.

How about the vehicle applications flow the same architecture?

arm has a list of problems for this idea and implementation 
And try to search solution 

## [SOAFEE and the Heterogeneous Road to Autonomy](https://techsymposia.arm.com/tw/sessions/Track_A4)

This talk is more about how to implement the previous talk: **[Automotive Products and Solutions for the Software Defined Vehicle](https://techsymposia.arm.com/tw/sessions/Track_A3)**.

This is the Cloud to Automotive Edge Environmental Parity 
* "The normal service in container over OS over virtual machine" vs. "The automotive service in the container over OS over real board".
* "The normal service in container over **RTOS** over virtual machine" vs. "The automotive service in the container over **RTOS** over real board".

If the cloud paririty happens, driving the virtual car on the **Cloud** virtual machines, for simulation, ML, verfication ... 

[Autoware Open AD Kit](https://www.autoware.org/autoware-open-ad-kit) provides a reference framework and solutions for it. 

However, there some gaps from common OS to Automotive OS:
* **VirtIO**
* Missing VirtIO interfaces
* CAN Bus
* Specialised accelerators
* ...
* Realtime and Functional Safety requirements
* What does a **real-time virtqueue** look like


* **Real-time Containers**
* The current OCI container runtime specification is **not real-time** aware
* Need to add **RTOS or Microkernel interface** capabilities into the upstream OCI specification


Need a way to update the software on the MCUs via Over-the-Air. We have general package management tools and [OSTree](https://ostree.readthedocs.io/en/latest/) for common OS. However, we do not have a standard one for RTOS. 

## [IoT Software Development Acceleration: Arm Virtual Hardware](https://techsymposia.arm.com/tw/sessions/Track_A5)

Train the models on the virtual hardwares. Then, transfer the model/result into software. Finally, deploy the software on the devices. 

[Qeexo](https://qeexo.com/) provides ML platform with [arm Virtual Hardware](https://avh.arm.com/). 

The [arm Virtual Hardware](https://avh.arm.com/) can be integrated with CI/CD. 

Real hardware constraints limit the use in a cloud native environment
* No scalability
* Complexity and high maintenance costs
* Limited ability to stimulate I/O


Virtual hardware levels 

[arm Virtual Hardware](https://avh.arm.com/) 
It supports RPi 4B as well!!! 

The [arm Virtual Hardware](https://avh.arm.com/) supports the idea of Could native development with SOAFEE 
So, developing the software and hardware parallelly is possible. 

## Project CASSINI

arm has the project [CASSINI](https://www.arm.com/solutions/infrastructure/edge-computing/project-cassini) for edge computing supported by:
* Standard - [arm SystemReady](https://www.arm.com/en/architecture/system-architectures/systemready-certification-program)
* Hardware, firmware
* Certification
* Security
* Security certification
* Open API for cross-platform securtity services
* Ecosystem


Cross the platforms/boards:

Debconf 22 has a talk: [SystemReady IR for Debian installation on imx8m boards.](https://debconf22.debconf.org/talks/19-systemready-ir-for-debian-installation-on-imx8m-boards/)