What is ExtVec3f for ?

[damienmarchal]

Small question to Sofa wizards..

• what is ExtVec3 for ?
• why do we have StdVec and ExtVec, isn't a single implementation possible ?
• why these two things are exposed up to the user layer ?

---

Suggested labels:

[damienmarchal]

On my side I really wonder what this things in bringing that the StdVec does not have.
@JeremieA, @fjourdes, any idea ?

[damienmarchal]

@guparan , @epernod , @fredroy any ideas ?
(because otherwise my next cleaning task will be to remove that :))

[damienmarchal]

It seems that no-one want to say anything about that :)

[hugtalbot]

On my best knowledge, it corresponds to a type for visualization/visual models.
Ext standing for external DOFs but this you already knew. I add this to the agenda of next week!

[damienmarchal]

Thank you Hugo.

[JeremieA]

The need for ExtVec came from two design goals:

1. for "default" state vector containers, using a vector that is compatible / derive from std::vector
2. for simulation outputs (i.e. to be sent to the GPU or wherever the application need), enabling support for "zero-copy" by allowing to specify an external pointer where the data should be written. For example, the pointer could be pointing to a mapped OpenGL VBO.

However, looking back at what was used in practice, both goals are not really useful:

• compatibility with std::vector makes it more complex to adapt features like GPGPU support, and is painful with visual c++ because of the awful debug performances it has
• no visual model were implemented taking advantage of the possibilities offered by ExtVec, and it is a bit of a mess to do because of the resize method that requires some virtual machinery (ResizableExtVec...).
• the copy-on-write feature that was later added in Data for thread safety and zero-copy links interferes (in an unspecified way) with the ability to force a given value to be stored in a specific location.

I would argue that the ideal design would be to have a single vector class for state vectors that:

• would not derive from std::vector (or do so privately)
• does not have any resize() method (so that all codes need to use mstate->resize() instead, insuring all vectors have a consistent size). Temporary/private vectors in other components could use a derived ResizableVec type adding resize().
• have a clear and simple design for externally-allocated buffers and synchronization mechanisms (both copy-on-write and on-GPU CUDA copies). there is a lot of common machinery between these features, i.e. an external buffer car be read/written but not reallocated, a copy-on-write buffer is readable only and must be copied to a new buffer if modified (and still shared), a GPU buffer may have a callback to be called before the next read or write operation (to copy latest values from GPU and/or wait for the last kernel that wrote it to finish)

This way a single DataTypes could be used for "normal" states, visual models, and GPGPU support.

But in the meantime just getting rid of ExtVec will do no harm that I know of ;)

[hugtalbot]

thank you for your feedback Jeremie, this will help the next steps a lot