esp32-s3 replacing some of ROM's linked functions for BIG optimisations. (IDFGH-15189)

[alhyene]

Is your feature request related to a problem?

Hi, All

I've disassembled some of my esp32-s3 codes and seen that they're linked with ROM's functions. It's good for space and ROM code execution that is faster than in the FLASH.

Then I've disassembled the esp32s3_rev0_rom.elf and seen it seem to never use the esp32-s3 PIE instructions set and maybe other specific opcodes. (not yet verified)

But I know by now the Espressif-Xtensa GNU like utilities, these one, don't use PIE or other enhancements than regular ISA instruction set, apart floating point ones for IEEE754 math functions. (not sure maybe some esoteric opcodes ones exists;)

Also I'm thinking why not patching some of the ROM's linked functions where benefits are significants. eg: replacing some math functions, memory transfert, ... with more powefull codes ?

And why not implementing the others opcodes ?
After all, it should be allful that Espressif-IDF integrate them when asked like with -O2, -03, ...., --optimisation-esp32-... ???

I'll wish to know if it's in the scope and maybe I could contribuate.

Wonderfull processors... 8-)

Describe the solution you'd like.

No response

Describe alternatives you've considered.

No response

Additional context.

No response

[igrr]

There are a few reasons why you don't see TIE instructions being used inside library functions in the ROM:

Timeline-related

Very often, the ROM for the upcoming chip is frozen earlier than the chip verification finishes. New features, such as TIE instructions, are often less stable and may take a couple of revisions to get right, so relying on them in mask ROM is risky. Therefore ROM uses safer and more stable (although less performant) implementations from newlib.

However, at the expense of some IRAM, we can replace a ROM function with a patched version, shipped as part of IDF.

TIE coprocessor context management overhead

Although TIE instructions may provide speedups by using a full throughput of the 128-bit data bus and by doing multiple arithmetic operations at once, they may also lead to performance loss in some cases. The main issue is that during task switching, TIE coprocessor state (register file) has to be saved and restored.

IDF uses "lazy" context switching for the FPU and other TIE instructions. This means that the corresponding part of the context is saved only if the task used the coprocessor. Otherwise, the coprocessor is simply kept disabled. When the task tries to use the coprocessor, an exception is raised, and the exception handler decides whether the task-specific FPU context has to be restored or not.

All this extra processing takes time — which may either be compensated for by the gains due to SIMD processing, or may actually make the performance worse. In our tests, a "memcpy" implementation based on TIE performs up to 4x faster than the original version from newlib, depending on the usage pattern. However overall benchmarks (such as TCP throughput) may be up to 8% lower, again depending on the usage pattern.

The most efficient usage of the coprocessor is when there is only one task per CPU which uses that coprocessor. In this case, no context saving and reloading is necessary. This scenario often occurs when the coprocessor is used for specialized workloads (neural networks, audio processing, etc.).

Coprocessor usage in interrupts and in the panic handler

The above mentioned lazy context switching also has to be taken into account when the function is called from an ISR. Currently, coprocessor usage in interrupts in IDF is very limited (only FPU is allowed, and only in Level 1 interrupts, see CONFIG_FREERTOS_FPU_IN_ISR).

If memcpy implementation starts using the coprocessor, we would need to either:

• check if memcpy is called from an ISR, fall back to the regular implementation (incurring extra run-time cost)
• modify the coprocessor context management logic in FreeRTOS port to allow usage in all ISR levels.

---

None of the issues above are impossible to solve, but they are also complex enough, and there is not enough improvement on real-world benchmarks (such as TCP stack throughput), so we didn't get around to optimizing generic libc functions.

However, in projects where the real-world benchmarks show higher improvement, some work has already been done. For example, esp_lvgl_port component uses TIE instructions for optimized blending and color fill operations.

[alhyene]

Hi,

I agree with the facts ROMs are early frozen and I don't like errata sheets... But it seem patching ROM functions is "well" implemented in ESPs but at the price of precious IRAM locations 'apart' if it could be implemented in the lazy FLASH, but don't know where're the benefits.

Speaking of a fully "real-time" multi-threaded environment it seem you're on right speaking of RTOS lazy switch context regarding FPU, TIEs but are we talking about CPUs or MCUs ? What type of applications it's supposed to made ? We have computers for doing these jobs !

I understand the boss's dilema tracking down employs doing their jobs and finaly in a loop everybody trying to control all the things spending time to control...

Maybe some functions could send values to RTOS like estimated elapsed time or telling what to await.
Sure like you said it should a better use of interrupts levels in the RTOS for such jobs with some semaphores mechanisnms like, and may be using timers ?

Finally, I really like your academic point of view !

8*)

[alhyene]

Hummm... Sorry I was a little bit out of subject...
In fact I'm tring to know why the compiler don't use TIE / extended fonctions for some algorithmics optimizations where it could be done, perhaps with some #PRAGMA or others mechanisms and maybe replacing some ROMs functions when needed.
Or implementing all of this by hands like the case of ESP-DSP or LVGL 9+ ?

[bryghtlabs-richard]

There's definitely room to optimize many of LVGL's blitters using the SIMD unit.