eigen3: UnalignedArrayAssert

[Sebastian Ordas]

Hello team, we are testing the Staple example on a virtual machine running kubuntu 14.04 LTS 32bits

We get the following assertion:

http://eigen.tuxfamily.org/dox-devel/group__TopicUnalignedArrayAssert.html

demo@demo:~/opensurgsim/OpenSurgSim/build/Examples/Stapling$ ./Stapling
Stapling: /usr/include/eigen3/Eigen/src/Core/DenseStorage.h:78: Eigen::internal::plain_array<T, Size, MatrixOrArrayOptions, 16>::plain_array() [with T = double; int Size = 16; int MatrixOrArrayOptions = 0]: Assertion `(reinterpret_cast<size_t>(eigen_unaligned_array_assert_workaround_gcc47(array)) & 0xf) == 0 && "this assertion is explained here: " "http://eigen.tuxfamily.org/dox-devel/group__TopicUnalignedArrayAssert.html" " **** READ THIS WEB PAGE !!! ****"' failed.
Aborted (core dumped)

How to overcome it? Any hint?

The pointer website suggests:

I don't care about vectorization, how do I get rid of that stuff?

Two possibilities:

• Define EIGEN_DONT_ALIGN_STATICALLY. That disables all 128-bit static alignment code, while keeping 128-bit heap alignment. This has the effect of disabling vectorization for fixed-size objects (like Matrix4d) while keeping vectorization of dynamic-size objects (like MatrixXd). But do note that this breaks ABI compatibility with the default behavior of 128-bit static alignment.
• Or define both EIGEN_DONT_VECTORIZE and EIGEN_DISABLE_UNALIGNED_ARRAY_ASSERT. This keeps the 128-bit alignment code and thus preserves ABI compatibility, but completely disables vectorization.

Is that an option? IF so, how shall I proceed?

many thanks!
sebastian

[Paul Novotny]

Hi Sebastian,

There is a cmake option that we added just for this case,
EIGEN_ALIGNMENT. It is an "advanced" option, so turn on advanced options
in cmake to see it. By default, we set eigen alignment to ON for 32 and
64 linux, and 64 bit MS Visual Studio builds. Since we only had trouble
with 32 bit Visual Studio builds. It is interesting that you are seeing
this, so I'll take a look into if we should turn this off by default for
32bit builds with gcc as well.

In the mean time, you can turn off EIGEN_ALIGMENT, and that should
address the issue. This will pass EIGEN_DONT_ALIGN to eigen, and turn
off vectorization as you mentioned below. Or, you could try a 64 bit
Ubuntu as we have had better luck with 64 bit OS's. In fact, I did test
Ubuntu 14.04 64bit during the release process so that should work with
eigen alignment on.

I would recommend trying to get your system to work with EIGEN_ALIGMENT
ON, it had a significant effect on our physics performance tests, I
think 2-3 times faster.

-Paul

On Mon, 2014-10-06 at 10:05 -0300, Sebastian Ordas wrote:
> Hello team, we are testing the Staple example on a virtual machine
> running kubuntu 14.04 LTS 32bits
>
> We get the following assertion:
>
> http://eigen.tuxfamily.org/dox-devel/group__TopicUnalignedArrayAssert.html
>
> demo@demo:~/opensurgsim/OpenSurgSim/build/Examples/Stapling$ ./Stapling
> Stapling: /usr/include/eigen3/Eigen/src/Core/DenseStorage.h:78:
> Eigen::internal::plain_array<T, Size, MatrixOrArrayOptions,
> 16>::plain_array() [with T = double; int Size = 16; int
> MatrixOrArrayOptions = 0]: Assertion
> `(reinterpret_cast<size_t>(eigen_unaligned_array_assert_workaround_gcc47(array))
> & 0xf) == 0 && "this assertion is explained here: "
> "http://eigen.tuxfamily.org/dox-devel/group__TopicUnalignedArrayAssert.html"
> " **** READ THIS WEB PAGE !!! ****"' failed.
> Aborted (core dumped)
>
> How to overcome it? Any hint?
>
> The pointer website suggests:
>
>
> I don't care about vectorization, how do I get rid of that stuff?
>
> Two possibilities:
>

> * Define EIGEN_DONT_ALIGN_STATICALLY. That disables all 128-bit static

> alignment code, while keeping 128-bit heap alignment. This has the
> effect of disabling vectorization for fixed-size objects (like
> Matrix4d) while keeping vectorization of dynamic-size objects (like
> MatrixXd). But do note that this breaks ABI compatibility with the
> default behavior of 128-bit static alignment.

> * Or define both EIGEN_DONT_VECTORIZE and

[Sebastian Ordas]

This 32b linux test was just to show your framework to a remote
colleague. I will ask him to disable it for now, but windows/linux 64b
wil be our working platform for sure.

thank you!

On 06/10/2014 10:24 a.m., Paul Novotny wrote:
> physics performance tests

[Paul Novotny]

On Mon, 2014-10-06 at 10:31 -0300, Sebastian Ordas wrote:
> This 32b linux test was just to show your framework to a remote
> colleague. I will ask him to disable it for now, but windows/linux 64b
> wil be our working platform for sure.

Great, let me know if you have any other questions. BTW, what input
devices do you use? The Stapling example is setup to run with a 3D
mouse, we use the 3Dconnexion SpaceNavigator here. It is easy to swap
out the 3D mouse and use our other supported devices (Phantom Omni,
Novint Falcon, Sixense Razer Hydra).

-Paul

[Sebastian Ordas]

We were trying to install an old Space Magellan ... (instead of buying a
wireless 3D connexion for $129 !!)

But we do also have a Razer Hydra! Is it possible to use it with the
Staple example?

Example´s CMakeLists says that Stapling should only be tested with
MULTIAXIS ...

if(BUILD_DEVICE_MULTIAXIS)
add_subdirectory(AddSphereFromInput)
add_subdirectory(Stapling)
endif(BUILD_DEVICE_MULTIAXIS)


On 06/10/2014 11:31 a.m., Paul Novotny wrote:
> Sixense Razer Hydra

[Paul Novotny]

On Mon, 2014-10-06 at 11:46 -0300, Sebastian Ordas wrote:
> We were trying to install an old Space Magellan ... (instead of buying a
> wireless 3D connexion for $129 !!)
>
> But we do also have a Razer Hydra! Is it possible to use it with the
> Staple example?

It would require a small code change to swap devices, I'll try out a
patch and send it over.

-Paul

[Sebastian Ordas]

ok, thank you. Please let me know if I can be of any help.

Are you guys using http://sixense.com/linuxsdkdownload for the Razor
Hydra in linux?

sixenseSDK_linux_OSX.zip

sebastian

[Paul Novotny]

I won't have time to test this, as I don't have the Sixense right now.
But I think the attached patch should do it. This is also in the
'stapling-sixense' branch on our Assembla repository:

git://git.assembla.com/OpenSurgSim.git

You will need to install the Sixsense SDK, I used this link:

http://sixense.com/linuxsdkdownload

You don't need to actually install this, just extract and set the
environment variable to it's location. ie, for me I did this:

export SIXENSE_ROOT=/home/paul/Desktop/sixenseSDK_linux_OSX/

BTW, when looking into this, I noticed there was a bug in the code that
finds the Sixense SDK. It is fixed in the second patch.

-Paul

[Sebastian Ordas]

thank you! I will report back my findings

sebastian