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
Right now, the estimated time for ffi is provided by a delay model, but that is typically not generated for external FFI functions, so it falls back to the ffi_fallback_delay_ps codegen parameter which is an estimate by the user and thus possibly pretty far off. Pipeline schedule will only be as good as the estimate of the parts.
As an alternative, if there is no accurate delay model characterization of the external module, we should use the delay we can determine from the IR for that particular function (as we always have that as fllaback). Even though it is not the same implementation as the external FFI module, it will provide a better estimate assuming similar implementation algorithms.
The text was updated successfully, but these errors were encountered:
Right now, the estimated time for ffi is provided by a delay model, but that is typically not generated for external FFI functions, so it falls back to the
ffi_fallback_delay_ps
codegen parameter which is an estimate by the user and thus possibly pretty far off. Pipeline schedule will only be as good as the estimate of the parts.As an alternative, if there is no accurate delay model characterization of the external module, we should use the delay we can determine from the IR for that particular function (as we always have that as fllaback). Even though it is not the same implementation as the external FFI module, it will provide a better estimate assuming similar implementation algorithms.
The text was updated successfully, but these errors were encountered: