You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
XX
XXX XX
X X
X X
X XX
X X
XX X
X X
X X
XX XX
X XXX
XXXXXXXXXXXXXXXX X
X
XXXXXXXXXXXXXXX
XX
XX
XX
XXXXXXXXXXXXXXXX
X
XXX
XXXXXXXXXXXXXX
XX
X
XXX
XXXXXXXXXXX
XXXX
XXXXXXXXXXXXXXXXX XX
XXXXX XX
XXXXXXXXXXXXXXXXXXX
After talking to Oliver and Frederic I've got the big picture and the details about this issue (joke aside). On P9, the main idea was to have NVLink associated to a cow ASCII art (which exists already in the code) whilst OpenCAPI associated to a capybara. Nonetheless, on an HMI event on machines supporting mixed nvlink and opencapi devices controlled by the NPU, like witherspoon machines, it's quite hard to differentiate if the HMI was generated by nvlink or by opencapi. Hence, the main issue is not so much about finding a proper ASCII Art with a doable license but rather to be able to differentiate precisely on a P9 machine that supports both nvlink and opencapi the right source of an HMI event.
That said, in case a future NPU implementation brings the ability to easily identify the HMI source, I provide a capybara v1 ASCII Art which was not copied from USENET, but brewed right out of the boredom in the covid19 quarantine.
It has proved incredibly useful to have an easily identifiable graphic indicating a broad error type.
The key for any ASCII art being added is for the license to be appropriate for inclusion (and not just "I copied this from USENET in 1987").
The text was updated successfully, but these errors were encountered: