Fix/pointer object #2
Conversation
|
Thanks for the contribution! Looks really good to me. VS code lag is real, though previously completions worked fine for me if I did not open So now, after splitting into multiple files, do completions not work with namespace import anymore? Did they work before for you? Given the API surface of Vulkan, writing individual imports would be massive pain. |
|
After splitting into multiple files, completion still works. Using namespace import now still will cause some lag but far more better than before. Using namespace import won't cause problems in running modules (except making first run wait longer), but will stop debugger to hit breakpoints. After playing around, I found that it is not caused by using namespace import, but by loading too many modules!!! If I remove a lot of unused struct re-exports, the debugger works fine with namespace import. I don't know if this is a problem happens only on my laptop. Maybe we could maintain a commonly used re-exports for structs. Users could do the same way if they encounter the same problem. Edit: |
|
It must be a performance problem in Deno LSP, probably worth reporting, though I'm not sure because in most cases it's unlikely one needs that much modules. About the common struct exports, that sounds good to me. Let's keep structs/mod.ts and add structs/common.ts and re-export structs/common.ts from main mod.ts. |
Problem found in the miss-alignment of `stage` in `VkComputePipelineCreateInfo`. Struct which has a field aligned with 8 should also be aligned with 8 as a field in other struct. Its alignment should be the largest alignment of its field's alignments, so that its fields could have correct alignments.
|
I put all the structs without vendor suffix and structs about debugs and swapchain in the common.ts. They are all the structs required by the two examples for now. I improved the compute example by adding a simple compute shader and a debug layer. The triangle example is also working now. But the compute example has a wired bug that sometimes might crash without any error messages. I doute it is caused by the incorrect struct size in a struct array which accessing the address out of the buffer. I think this PR has done what it says, and other fix should makes new PRs. |
This PR makes two major changes:
The first change is the fix of
Deno.PointerValue.Deno.PointerValuebecomesPointerObject | nullsince Deno v1.31.1. Basically, we still store pointers asUBigInt64in struct buffers, but convert them intoDeno.PointerValues when passing to ffi.The second change is to split big vk.ts into multiple files. This is aggressive. The main reason is that every time I open vk.ts my vscode become very lag and the code completion is freeze. Besides, if I write something like
import * as vk from "mod.ts", the same thing will happen. Even worse, the debugger won't hit any breakpoint if I use the namespace import. Something I can not understand. But if I import symbols from individual files, everything works smoothly, even the debugger.