Page MenuHomeFreeBSD

riscv: vector extension support
Needs ReviewPublic

Authored by br on Wed, Apr 15, 4:00 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Apr 24, 3:02 PM
Unknown Object (File)
Wed, Apr 22, 1:57 PM
Unknown Object (File)
Sun, Apr 19, 8:36 AM
Unknown Object (File)
Sat, Apr 18, 5:43 AM
Unknown Object (File)
Sat, Apr 18, 5:43 AM
Unknown Object (File)
Sat, Apr 18, 5:05 AM
Unknown Object (File)
Fri, Apr 17, 2:16 PM
Unknown Object (File)
Fri, Apr 17, 12:12 PM
Subscribers

Details

Reviewers
jrtc27
Group Reviewers
riscv
Summary

RVV is a scalable SIMD (Single Instruction, Multiple Data) extension designed to accelerate data-intensive workload such as AI, machine-learning and DSP.

RVV exposes vector-length agnostic (VLA) execution and programming model, with implementation defined vector register file size, dynamic vector length selection, flexible register grouping, and rich instruction semantics, serving as the foundation for portable, high-throughput data-parallel acceleration.

https://github.com/riscvarchive/riscv-v-spec/releases/download/v1.0/riscv-v-spec-1.0.pdf

RVV extends a base scalar RISC-V ISA with 32 vector registers and seven unprivileged control-status registers (CSRs) to control the engine. Each vector register could be up to 2^16 bits in length, depending on implementation.

  • Detect the extension during boot time ("v" letter in the ISA string)
  • Implement RVV management code in the machine-dependent interfaces that handle CPU and thread state
  • Add memory-management code for vector state save area. The allocation for save area in thread's PCBs has to be dynamic as the length of registers varies across implementations
  • Save and restore RVV state on context-switch, fork(), scheduler entry, etc
  • Enable the extension usage on the first instruction trap from userspace ("lazy" enable)

No support for ucontext.h posix API (looks like legacy)

Test Plan

Tested in QEMU

Diff Detail

Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

br requested review of this revision.Wed, Apr 15, 4:00 PM
br created this revision.

No support for ucontext.h posix API (looks like legacy)

This does need to work; what does Linux do?

Cool! A couple initial things.

sys/riscv/riscv/swtch.S
507

Save vector state here too?

sys/riscv/riscv/vector.c
38–39

The naming is wrong.

It seems that (unlike arm64) we are keeping vector code distinct from FPU code.

FPU kernel state is still to come, and this is for user contexts.

sys/riscv/riscv/vm_machdep.c
189

I need to return to the dropped conversation in D53804.

It's my belief that the same possibility for stale data exists here, as in cpu_fork(), and we should update the PCB with both FP and vector state.

Not empirically validated.