Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

eStorage tensor fix, eval clears operations in sequence, added one test and modified tests that were broken #304

Closed
wants to merge 14 commits into from

Conversation

MiroPalmu
Copy link
Contributor

@MiroPalmu MiroPalmu commented Sep 16, 2022

This might might be too large PR. Sorry about that. Because of my mistake PR #302 is also included in this.

Two main things are that we can now create eStorage tensors with nullptr as data without undefined behaviour and evalAwait (and functions calling it) now clear operations stored in sequence.

  1. eStorage changes

Added a concept "device only" tensors that can be checked with isDeviceOnlyTensor(). At the moment eStorage is only device only tensor.

This is used to determine if we need to do raw data mappings and unmappings. Also in postEval of OpTensorCopy made it such that it does not copy raw data if the tensor that we copy from is device only nor it does not copy raw data to a tensor that is device only.

This fixes undefined behaviour that we had with eStorage tensor. Now we can create device only tensors with manager by setting data to nullptr.



// Create device only tensor with 10 floats
auto tensor = mgr.tensor(nullptr, 10, sizeof(float), kp::Tensor::TensorDataTypes::eFloat, kp::Tensor::TensorTypes::eStorage);

I added one test about copying in and out from eStorage tensors.

  1. eval changes

Motivation behind changes: There was lot of tests that were chaining evals together. For example


    mgr.sequence()
      ->eval<kp::OpTensorSyncDevice>({ tensorA })
      ->eval<kp::OpTensorCopy>({ tensorA, tensorB });

This is straight up broken because we never clear vk::CommandBuffer nor operations stored in the sequence. When second eval is called it runs OpTensorSyncDevice again because it never got cleared form the sequence. This can be checked from the logs.

Because I think chaining evals is quite intuitive api and I like it I wanted to fix this so what I propose is that evalAwait would always clear the operations stored in the sequence. So now you have to manually record operations again but I don't think this is a problem.

I added vk::CommandBufferUsageFlagBits::eOneTimeSubmit to command buffer create info such that we are sure vk::CommandBuffer gets cleared every time we start record to it.

With this change some tests got broken or they had bugs in them. I also fixed them.

Signed-off-by: Miro Palmu <miro.palmu@helsinki.fi>
Signed-off-by: Miro Palmu <miro.palmu@helsinki.fi>
Signed-off-by: Miro Palmu <miro.palmu@helsinki.fi>
Signed-off-by: Miro Palmu <miro.palmu@helsinki.fi>
Signed-off-by: Miro Palmu <miro.palmu@helsinki.fi>
Signed-off-by: Miro Palmu <miro.palmu@helsinki.fi>
Signed-off-by: Miro Palmu <miro.palmu@helsinki.fi>
Signed-off-by: Miro Palmu <miro.palmu@helsinki.fi>
Signed-off-by: Miro Palmu <miro.palmu@helsinki.fi>
…s recorded to sequence

Signed-off-by: Miro Palmu <miro.palmu@helsinki.fi>
Signed-off-by: Miro Palmu <miro.palmu@helsinki.fi>
Signed-off-by: Miro Palmu <miro.palmu@helsinki.fi>
Signed-off-by: Miro Palmu <miro.palmu@helsinki.fi>
Signed-off-by: Miro Palmu <miro.palmu@helsinki.fi>
@MiroPalmu MiroPalmu mentioned this pull request Sep 16, 2022
@MiroPalmu
Copy link
Contributor Author

BTW I did not figure out hot to generate doctrings.hpp automatically so I modified it manually.

@axsaucedo
Copy link
Member

Closing as superceeded by #316

@axsaucedo axsaucedo closed this Dec 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants