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

va:add synchornization fence for HW execution #810

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

XinfengZhang
Copy link
Contributor

@XinfengZhang XinfengZhang commented May 11, 2024

do not merge!
add fence in and fence out for vaEndPicture which is using to submit command buffer fence out will be signaled after HW execution, fence in is the dependencies

@ceyusa
Copy link
Contributor

ceyusa commented May 13, 2024

is this Linux only?

@XinfengZhang
Copy link
Contributor Author

is this Linux only?

good question, it is for a linux PoC , will not merge until we could verify it.
I suppose we could refer vulkan vkSemaphore or vkFence in future to support all OS in future.
such as: add a interface to createsyncobj and destroysyncobj, the syncobj could be used to encapsulate different OS sync object.

va/va.h Outdated
Comment on lines 4178 to 4179
* Same behavior with vaEndPicture except a sync fd list for synchronizations.
* if sync_num = 0 or sync_fds == NULL, the behavior should be same with vaEndPicture.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be: "Same behaviour as" and ... "the behaviour should be the same as vaEndPicture()"

* current frame finishing.
* sync_fds[1] to sync_fds[1 ~ sync_num-1] is fence in, current HW execution
* will be blocked until all these fences are signaled.
* these fence fds is file descriptor of dma_fence.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible to call vaEndPicture2() with a fence-out but no fence-in(s)? If so it'd be good to specify it in this function comment (and maybe other expected example use patterns);

VAStatus vaEndPicture2(
VADisplay dpy,
VAContextID context,
int32_t *sync_fds,

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any advantage in bundling fences out and in vs e.g.

   int32_t *sync_fd_out,     // Out. Can be nullptr.
   int32_t* sync_fds_in,     // In. Can be nullptr.
   int32_t sync_fds_in_num,  // In. Can be 0.

Or something like that?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

both ok to me, but now , it is just a PoC, and the implementation is ready here:
intel/media-driver#1803

in the future:

  1. libva should support both linux and windows, so, we will have some other interfaces to hide the dma fence, unify the syn definition in future.
  2. decouple the fence in and out to too parameters as your mentioned.

add fence in and fence out for vaEndPicture which is using to submit command buffer
fence out will be signaled after HW execution, fence in is the dependencies

Signed-off-by: Carl Zhang <[email protected]>
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.

3 participants