diff options
| author | open-iov <open-iov@localhost> | 2026-10-25 19:38:26 -0400 |
|---|---|---|
| committer | open-iov <open-iov@localhost> | 2026-10-25 19:38:26 -0400 |
| commit | d09be8f621571893c79458bde601894e6fb3f0e1 (patch) | |
| tree | ff455209bc49c49e689c1cad0243ba3c9ca913ce /userspace/lib/libvgpu.pc.in | |
| parent | 9e6324f39e9e149a379ae6a17563ddffd6bf99f9 (diff) | |
| download | open-iov-d09be8f621571893c79458bde601894e6fb3f0e1.tar.gz open-iov-d09be8f621571893c79458bde601894e6fb3f0e1.zip | |
tools/guest-diag: fenceword_assist.py - host assist that releases the live vk_frame120 Vulkan fence wait word (session 125): the fence word is the +0x90 slot of the same 16 KB /dev/nvidiactl BO whose +0x80 slot carries the t122 BW init wait word; the assist finds the BO in the client's rw-s mappings (init word 1, fence word 0) and writes 1 to +0x90 per submit. With it, the t122 client reaches VKFRAME seq=1..3/DONE and writes real PPMs to /tmp/vkout (r715: vk-0001..0003.ppm, content still black - the GR shader work is the next gate, not the fence). This tool is the direct predecessor of the service-side fold: the submit push carries an INC-5 group targeting the same slot (observed [2005c017][0x45ba090][0][payload 1][0][0x02100001]) and the service's translation for that VA is correct (verified against the client pagemap), but the group sits in a push region the decoded entry windows do not cover - next: dump the full 11-entry rings and find/cover that entry.
Diffstat (limited to 'userspace/lib/libvgpu.pc.in')
0 files changed, 0 insertions, 0 deletions