-
Notifications
You must be signed in to change notification settings - Fork 11
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
We must block on all pending work during flush() #39
Comments
This part seems to be fixed:
But the core issue here still remains. Actually, the more I think about this, the more I see that the problem is in a lower layer. We should try to avoid this scenario:
With the current code, there is no way to tell Rust of B's relationship on A. In particular, as we're simply sending their surface IDs to the libva driver using an unsafe block, no guarantees apply. A way to solve this is to patch this guy:
We can populate
Under my proposed solution, we could, for example:
Now, after we transition from PictureEnd to PictureSync we do not care about dependencies anymore because all data has been processed by the driver already. So in the transition from PictureEnd to PictureSync we can clear them:
@Gnurou WDYT? |
This appears to be a bug in our implementation. If we flush, we must
a) submit any leftover work
b) block on said work before returning
Notice that after we return from flush, a lot of our state is (or will be) invalid, so we must complete the work before returning.
For h.264, for example, the current code will not check
cur_pic_opt
, nor will it block on it. This means that if (for whatever reason),cur_pic_opt
isSome
, that picture will be lost.The text was updated successfully, but these errors were encountered: