Записки CPU designer'a

Первые идеи для векторной спецификации RISC-V V 2.0

Одно из преимуществ открытой архитектуры это то что в live-режиме можно следить за технической дискуссией при выборе тех или иных решений и подходов при составлении архитектурной спецификации. Не так давно Qualcomm выступали с предложениями о пересмотре набора обязательных расширений для профиля RVA и подготовили ряд докладов о проблемах compressed расширения RISC-V.

Сегодня поговорим о предложениях (ключевое слово предложениях) одного из участников SIG: Vector Jose Moreira (Chair, IBM).

Одно из обсуждаемых решений в текущей имплементации векторной ISA - это конфигурационные инструкции, которые обновляют CSR. Эти инструкции находятся как бы на границе двух пайплайнов - векторного и системного (который отвечает за обновление конфигурации ядра) и имплементация данных инструкций нетривиальная задача. Однако, данные инструкции дают нативную поддержку stripmining vector. О примере имплементации таких инструкций писал в посте про RISC-V Ocelot.

Jose M. предлагает концепт Self-contained vector ISA, когда конфигурация вектора уже закодирована в самой инструкции. Но цена такого подхода - это расширение инструкции до 64-бит (либо до 48 бит), чтобы вместить те данные, которые в текущем подходе сохраняются в векторных CSR.

Какие плюсы можно выделить в этом подходе, по мнению автора канала:
1) повышение производительности за счет "высвобождения" системного пайплайна скалярного ядра;
2) простота отладки, т.к. каждая инструкция содержит конфигурацию вектора;

Минусы:
1) усложнение процесса извлечения инструкций - теперь нужно не только уметь извлекать и различать 16 битные инструкции и 32 битные, но и 64-битные;
2) усложнение логики branch predictor для корректного предсказания перехода с 3 типами длин инструкций;
3) усложнение логики скалярного декодера для различия compressed, non-compressed и 64-битных векторных инструкций;
4) если раньше скалярное ядро было драйвером VPU, то теперь обработка конфигурации вектора, определение запрещенных конфигураций будет обрабатываться внутри векторного конвейера;

Вместо заключения
Наличие 3 различных длин перегружает и усложняет fronted ядра фактически на всех этапах и делается в шаг, пусть и к размытой, нечеткой границе CISC подхода. Хотя задача изменения конфигурации вектора является важной, она не встречается достаточно часто в прикладных задачах, чтобы считать конфигурационные инструкции существенным bottleneck'ом в векторном расширении. Автору канала сложно понять мотивацию предложения нового формата векторного расширения, с акцентом на отказе от конфигурационных инструкций. Похоже, что в данном решении баланс между аппаратной поддержкой и бенефитами, которые оно предоставляет, не полностью продуман.

А в качестве вводной лекции про дизайн и микроархитектуру VPU предлагаю ознакомиться с презентацией от Tenstorrent.

К обсуждению приглашаю всех в комментарии к посту 🤓

GitHub

vector/minutes/2023/2023-11-20 at main · riscv-admin/vector

Group administration repository for SIG: Vector. Contribute to riscv-admin/vector development by creating an account on GitHub.

www.tgoop.com/cpu_design/157

3.0K viewsНиколай, edited  Dec 10, 2023 at 15:39

Первые идеи для векторной спецификации RISC-V V 2.0

Одно из преимуществ открытой архитектуры это то что в live-режиме можно следить за технической дискуссией при выборе тех или иных решений и подходов при составлении архитектурной спецификации. Не так давно Qualcomm выступали с предложениями о пересмотре набора обязательных расширений для профиля RVA и подготовили ряд докладов о проблемах compressed расширения RISC-V.

Сегодня поговорим о предложениях (ключевое слово предложениях) одного из участников SIG: Vector Jose Moreira (Chair, IBM).

Одно из обсуждаемых решений в текущей имплементации векторной ISA - это конфигурационные инструкции, которые обновляют CSR. Эти инструкции находятся как бы на границе двух пайплайнов - векторного и системного (который отвечает за обновление конфигурации ядра) и имплементация данных инструкций нетривиальная задача. Однако, данные инструкции дают нативную поддержку stripmining vector. О примере имплементации таких инструкций писал в посте про RISC-V Ocelot.

Jose M. предлагает концепт Self-contained vector ISA, когда конфигурация вектора уже закодирована в самой инструкции. Но цена такого подхода - это расширение инструкции до 64-бит (либо до 48 бит), чтобы вместить те данные, которые в текущем подходе сохраняются в векторных CSR.

Какие плюсы можно выделить в этом подходе, по мнению автора канала:
1) повышение производительности за счет "высвобождения" системного пайплайна скалярного ядра;
2) простота отладки, т.к. каждая инструкция содержит конфигурацию вектора;

Минусы:
1) усложнение процесса извлечения инструкций - теперь нужно не только уметь извлекать и различать 16 битные инструкции и 32 битные, но и 64-битные;
2) усложнение логики branch predictor для корректного предсказания перехода с 3 типами длин инструкций;
3) усложнение логики скалярного декодера для различия compressed, non-compressed и 64-битных векторных инструкций;
4) если раньше скалярное ядро было драйвером VPU, то теперь обработка конфигурации вектора, определение запрещенных конфигураций будет обрабатываться внутри векторного конвейера;

Вместо заключения
Наличие 3 различных длин перегружает и усложняет fronted ядра фактически на всех этапах и делается в шаг, пусть и к размытой, нечеткой границе CISC подхода. Хотя задача изменения конфигурации вектора является важной, она не встречается достаточно часто в прикладных задачах, чтобы считать конфигурационные инструкции существенным bottleneck'ом в векторном расширении. Автору канала сложно понять мотивацию предложения нового формата векторного расширения, с акцентом на отказе от конфигурационных инструкций. Похоже, что в данном решении баланс между аппаратной поддержкой и бенефитами, которые оно предоставляет, не полностью продуман.

А в качестве вводной лекции про дизайн и микроархитектуру VPU предлагаю ознакомиться с презентацией от Tenstorrent.

К обсуждению приглашаю всех в комментарии к посту 🤓

BY Записки CPU designer'a