---
# System prepended metadata

title: 'SparseBLAS Meeting May 23, 2024'

---

# Sparse BLAS Standing Meeting May 30, 2024

## Agenda

- Ben presents CSR object implementation.
- We put together a short survey asking for feedback whether library-internal memory allocation in the vein of what Ben presented is wanted

## Notes

# Sparse BLAS Standing Meeting May 23, 2024

## Agenda

## Notes

- Tim Davis, others: The `info` object being named "info" is confusing.
    - Comment from Ben: the motivation to name the object `operation_info_t` comes from its semantic behavior. Primarily, the `info` object provides information about the operation's output matrix (the shape of the output and its number of nonzeros, for sparse outputs). These are then used by users to allocate sufficient space for the output to be written. i.e., the `info` object's semantic purpose is to provide this information to the user through the public `.result_nnz()` and `.result_shape()` methods. The `info` object may also be used by a vendor-optimized implementation to store operation-specific state, but this is not semantically visible to the user.
    - Comment from all: it's still confusing, though.

- Question from Manu: How would this info object work? Is the vendor-specific state visible?
    - Ben: We have an [implementation of `operation_info_t`](https://github.com/SparseBLAS/spblas-reference/blob/main/include/spblas/detail/operation_info_t.hpp#L30).  In it, vendors can add a private member to `operation_info_t` that stores operation-specific state.

- Federico: we could also introduce matrix-specific optimization data or a matrix object.
    - Ben: Yes, we reached a consensus to introduce matrix-specific optimization data through a mix-in approach, but this has not been implemented yet.

- Hartwig: Do we have consensus to just use views? All of the vendor libraries currently rely on views where the user is responsible for allocating all data.
    - Federico: Well, yes, we do this in cuSparse, but begrudgingly. We would prefer an object-based approach.
    - Ben: an object-based matrix is possible, but it introduces issues with device memory. An allocator by itself is not sufficient to tell us how to manipulate device memory (unless each vendor implements their own matrix object). This is necessary with an object in order for it to be initialized in a valid state.
    - Mike Tsai: We could have a one-shot implementation where the view's data is re-allocated by the implementation using a user-provided allocator.  I have implemented this in CUDA.
        - Ben: This works, but it breaks the semantics of users always allocating the data that backs views. I think it will be confusing for users--do they need to de-allocate the old data that was in the view? What about the new data. We can define these semantics in documentation, but it may still be confusing.

## Outcomes
- Ben to implement a CSR object with device memory to show what would be necessary.

