Skip to content

Conversation

@gagicb
Copy link
Contributor

@gagicb gagicb commented Dec 11, 2025

Using a texture handle after calling cudaDestroyTextureObject results in undefined behavior.
In GFTT/corners, we had the following sequence:

Enter function F
Create texture T
Launch kernel K on stream S
Return from function F, which destroys texture T

At step 4, we must guarantee that kernel K launched on stream S has completed and that T is no longer used before it is destroyed. Thats why I added stream synchronization before function return.

Relevant description from the CUDA SDK documentation:

https://docs.nvidia.com/cuda/cuda-runtime-api/group__CUDART__TEXTURE__OBJECT.html#group__CUDART__TEXTURE__OBJECT__1_gae41ef138ba69d54b91068247f8f6c4e8:~:text=Use%20of%20the%20handle%20after%20this%20call%20is%20undefined%20behavior.

Pull Request Readiness Checklist

See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request

  • I agree to contribute to the project under Apache 2 License.
  • To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
  • The PR is proposed to the proper branch
  • There is a reference to the original bug report and related work
  • There is accuracy test, performance test and test data in opencv_extra repository, if applicable
    Patch to opencv_extra has the same branch name.
  • The feature is well documented and sample code can be built with the project CMake

@asmorkalov
Copy link
Contributor

cc @cudawarped

@asmorkalov
Copy link
Contributor

@gagicb Could you add some issue description and why you add the synchronization for non-default stream. Some reference to documentation is useful too.

@gagicb
Copy link
Contributor Author

gagicb commented Dec 16, 2025

@gagicb Could you add some issue description and why you add the synchronization for non-default stream. Some reference to documentation is useful too.

Hi @asmorkalov,

Using a texture handle after calling cudaDestroyTextureObject results in undefined behavior.
In GFTT/corners, we had the following sequence:

  1. Enter function F
  2. Create texture T
  3. Launch kernel K on stream S
  4. Return from function F, which destroys texture T

At step 4, we must guarantee that kernel K launched on stream S has completed and that T is no longer used before it is destroyed. Thats why I added stream synchronization before function return.

Relevant description from the CUDA SDK documentation:

https://docs.nvidia.com/cuda/cuda-runtime-api/group__CUDART__TEXTURE__OBJECT.html#group__CUDART__TEXTURE__OBJECT__1_gae41ef138ba69d54b91068247f8f6c4e8:~:text=Use%20of%20the%20handle%20after%20this%20call%20is%20undefined%20behavior.

Best regards,
gagik

@asmorkalov asmorkalov self-assigned this Dec 16, 2025
@asmorkalov asmorkalov merged commit d99ad2a into opencv:4.x Dec 16, 2025
23 of 25 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants