8000 Preserve device offsets in driver resource descriptors by RicheyWorks · Pull Request #56 · jcuda/jcuda · GitHub
[go: up one dir, main page]

Skip to content

Preserve device offsets in driver resource descriptors - #56

Draft
RicheyWorks wants to merge 1 commit into
jcuda:masterfrom
RicheyWorks:fix/resource-descriptor-pointer-offsets
Draft

RicheyWorks wants to merge 1 commit into
jcuda:masterfrom
RicheyWorks:fix/resource-descriptor-pointer-offsets

Conversation

@RicheyWorks
Copy link
Copy Markdown

Driver resource descriptors currently marshal linear_devPtr and pitch2D_devPtr with getNativePointerValue, dropping the offset carried by CUdeviceptr.withByteOffset. Creating a texture from a valid aligned suballocation consequently binds the allocation base instead of the requested region. The reverse conversion also leaves an old Java offset attached when writing a complete returned native address into a reused descriptor.

Use the existing offset-aware getPointer helper for both device-pointer inputs, and setPointer for both returned pointers so stale offsets are cleared. Array/mipmapped-array handles and JNI signatures are unchanged. This is one descriptor-pointer round-trip fix covering linear and pitched memory.

Add eight real driver cases: linear/pitched resources, fresh/reused output descriptors, zero/shifted pointers. Query the actual resource address via cuTexObjectGetResourceDesc before checking the reused descriptor, so offset cancellation cannot mask a wrong binding. Use device-reported alignment, tiny allocations, private CPU-thread contexts and finally cleanup. No kernels, sampling operations or device reset.

Verification:

  • Published 12.6.0 DLL: eight cases, four shifted cases fail; CUDA reports the allocation base, 512 bytes before the expected address on the test device. Zero-offset controls pass.
  • Rebuilt complete driver JNI DLL with this four-line change against unchanged upstream shared utilities (jcuda-common commit 9d41fb5): all eight pass under -Xcheck:jni, with no JNI warnings. JVM logging confirms the rebuilt DLL path. This does not require the separate common copy-back fix.
  • Windows x86_64, RTX 4090/driver 617.42, Temurin JDK 22, declared JUnit 4.13.1; MSVC/CMake and verified CUDA 12.6 workspace headers/import library. Java compilation uses the separately proposed parent baseline in Target Java 8 in the parent compiler configuration jcuda-parent#2 installed normally.
  • No full CUDA suite, runtime-API equivalent, texture sampling/rendering, other OS or GPU model was validated. Other workloads were not paused or reset.

CUDA contract: https://docs.nvidia.com/cuda/archive/12.6.0/cuda-driver-api/group__CUDA__TEXOBJECT.html

Focused test after rebuilding JNI:

mvn -f JCudaJava/pom.xml -Dtest=JCudaDriverResourcePointerOffsetTest "-DargLine=-Xcheck:jni -Djava.library.path=<rebuilt-driver-directory>" test

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.

1 participant

0