Vector TG meeting tomorrow
I will add my thoughts related to "embedded" imprecise:
Why embedded specifically?
Linux handles GPUs as coprocessors. My understanding is that by their nature, the internal state of most GPUs is not precisely known, but it can be and is managed as a black box.
What is distinct or special about embedded that makes embedded more [or less] inclined/susceptible to vector imprecise state?
What makes our vector engine less managable/usable/precise if
the unit has to be managed as a black box?
It is important to make a distinction between
- precise identification of the element/component requiring intervention (whether that be emulation/reconfiguring the system for instruction completion, etc.) and
- precise state of all the components in the
coprocessor/attached-device, etc. is readily known/discoverable.
I don't know if we are only discussing "imprecise" as defined in
the Vector spec.
(There is an issue open about that that is not embedded specific.
Or are we expanding from 1 the number of vector registers that can be affected by concurrent vector operations.
On 2020-10-02 5:36 a.m., David Horner via lists.riscv.org wrote:
toggle quoted message Show quoted text
Is there already a doc/issue specific to this imprecise handling that we can reference before and during the meeting?
On Fri, Oct 2, 2020, 03:46 Krste Asanovic, <krste@...> wrote:
Reminder we’ll be meeting tomorrow in usual slot.
I’d like to spend the time discussing imprecise trap handling for embedded vector systems.
Hopefully, we can all see the new correct link on Google Calendar for meeting info.
|1 - 3 of 3|