Re: Vector TG meeting tomorrow

David Horner

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.

(#364 again).

On 2020-10-02 5:36 a.m., David Horner via wrote:

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.

I replaced old calendar entry with message not to use this entry.


Join to automatically receive all group messages.