Draft: Partial vectorization for Hexagon DSP HVX

What does this implement/fix?

Additional optimization for vectorization using HVX on the Hexagon DSP. HVX uses 128-byte vector registers so vectors and matrices with sizes that don't fit 32 elements have quite some overhead. With this change we want to enable using shorter packets as well with the HVX register.

This change focuses on dynamic vectors and operations on the dynamic vectors. We add some extra memory to the dynamic vectors to avoid reading invalid memory when reading a full HVX register.

This is a first contribution for us. Any suggestions for improvements and aligning with the Eigen code base are very welcome. Thank you!

Additional information

This is in addition to the work from Cheng Wang and comes independently from Qualcomm.

This is a common assumption, I don't think we need the asserts.

ok, thanks for the hint.

Why is this needed?

Ah, I see from the MR description.

This doesn't fix the reading-past-the-end issue for fixed-sized matrices. Those tail values are also uninitialized. It would be better if there were a true masked load.

yes, it doesn't address fixed size objects like this. We are looking at working with a masked load, so I hope we can avoid this in the end.

It would be nice to unify this whenever partial loads/stores are available.

Is there a way to test this? Maybe a docker image that provides the SDK, plus emulation?

thank you for reviewing this. We are working on providing a docker image for testing, but that will probably take a few weeks (SDK distribution question).

So, we will update this merge request first to see if we can avoid the extra buffer and your other comments.

thanks!

Thanks for the update.

do you have any requirements for a docker image? like preferred Linux base image? we could go with a recent ubuntu image like 22.04

No preference - just something we can set up for the CI.

Hi @cantonios, I work with Gerhard at Qualcomm and am looking into the docker setup for libeigen testing on hexagon. I am coordinating with another team inside Qualcomm on this and I think it would be useful if we can get on a short 30min call to discuss the logistics of the installation of tools needed to perform hexagon testing. Please share some time slots next week if you are ok with a call. You can reach me at abisain@qti.qualcomm.com

@cantonios, the Docker image we had in mind is in !1634 (closed). Please take a look. It requires one-time creation of a Qualcomm Developer account and some click-through agreements in order to install the Hexagon SDK into a base testing image. This Dockerfile is re-distributable, but the resulting docker image would not be. To reduce the overhead of generating the image each time you could re-use the image privately in your CI system as long as the image is not publicly distributed.

This has some common elements in it.

!1348 (closed)

requested review from @rmlarsen1

requested review from @cantonios

requested review from @chuckyschluz

mentioned in merge request !1695

closed

I closed this MR because it is superceded by !1695.