-
Notifications
You must be signed in to change notification settings - Fork 244
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
Add debug_printf!
and debug_printfln!
macros that uses the DebugPrintf extension
#768
Conversation
This reverts commit 6a21a29.
… blocking the in(reg)
printf
and printfln
macros that uses the DebugPrintf extensionprintf!
and printfln!
macros that uses the DebugPrintf extension
Actually, I do get this validation error so it's not like the segfault is coming out of nowhere: |
Fun fact: you can print emojis using these macros. I was pleasantly surprised that unicode didn't get mangled somehow. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be nice to add some sort of check on vulkan to avoid the "Mixed stage shader module not supported" obscure issue, seems pretty confusing especially if validation layers are disabled.
It's also rather unfortunate that we can't do typechecking on the format string, that really sucks, but oh well I guess.
Also, I have a vague preference to call it debug_printf
, but I could go either way.
Out of curiosity, what's the error message when calling it outside of an unsafe
block?
I think we probably could do some kind of typechecking. If we had a function like this: fn assert_is_type<T>(ty: T) -> T {
ty
} we could map each format argument to the rust type - What I believe we can't do is any kind of type inference.
👍
It's the same as calling an |
I did a test of this (just assuming every format argument is error[E0308]: mismatched types
--> $DIR/debug_printf.rs:41:31
|
41 | debug_printfln!("%f", vec);
| ^^^ expected `f32`, found struct `Vec2` Commit: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fantastic! feel free to merge the typechecking, too, that'd be really nice to have.
crates/spirv-std/macros/src/lib.rs
Outdated
quote::quote! { spirv_std::debug_printf_assert_is_vector::<#ty, _, #count> } | ||
} else { | ||
let ty = map_specifier_to_type(specifier); | ||
quote::quote! { spirv_std::debug_printf_assert_is_type::<#ty> } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't like that this assumes that spirv_std
is in scope like this. Not sure what else we can do though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like it's an open issue rust-lang/rust#54363
crates/spirv-std/macros/src/lib.rs
Outdated
"ul" => quote::quote! { u64 }, | ||
"lu" => quote::quote! { u64 }, | ||
"lx" => quote::quote! { u64 }, | ||
_ => unreachable!(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just realized, there's no support here for f64 or int sizes under 32 bits - I would have expected there to be support, where are you finding the docs for what specifiers correspond to what types? sorry, missed the bit in the linked document
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh haha, I actually missed the
- No length modifiers. Everything except ul, lu, and lx is 32 bits, and ul and lx values are printed in hex
line when I read the document before, it's good to know that this is doing things correctly.
I had to change how this does argument count checking, as debug_printf!("%r", 11_i32); was being accepted as invalid before when it shouldn't have been. I also added a We have another slight problem though that it won't accept debug_printfln!("%%r %%f"); as valid even though it should. I'm not sure if we can change the regex to check for an odd number of This is getting into edge-cases though. Not sure how much effort should be put into those. |
Is it actually specified/defined what the behavior of As for parsing validity, the proper solution here is probably to drop the regex and do lexing ourselves - regex probably isn't the right tool for this job.
Compilers are entirely about edge cases, this is really important to get right~ |
Just tested this - it just prints
Yeah, it almost certainly isn't.
For sure :) but right now, I don't think anyone would really mind if they had to do |
what in the absolute heckity goodness, lmao, that's wild anyway, yeah, probably fine to merge as-is and work on full validation later if you'd prefer that PR model! as for the path test failure, I thiiink there might be a way to work around that with something like this, although that might have to be tweaked slightly (not sure - might be fine copypasting that as-is? - it's been a long time since I've dealt with a failure like that) |
C does the same thing actually 😅😅😅 at least you get a warning
I do generally prefer making more small PRs but here I'd like to work on the validation more before merging. Is there any way of lexing that would be best or you'd prefer? I feel like just iterating over the string and doing a bit of look-ahead would work fine. |
Yeah, sounds fine! There's the bit of lexing in this project I did here, something like that, or whatever lookahead stuff you think might make things cleaner. |
Okay, I've got something that works quite well now. It could be a bit more concise though. |
heck yeah, that looks super good! thanks so much for doing that~ |
printf!
and printfln!
macros that uses the DebugPrintf extensiondebug_printf!
and debug_printfln!
macros that uses the DebugPrintf extension
🎉 |
See #151.
This will probably require some work before being merged. These macros and different from the core rust
print
andprintln
macros as the type of variables needs to be specified in the format string. There's probably a way to change this as mentioned here: #151 (comment) but for now I'm doing the simpler thing.I have a branch here: main...expenses:printf-working that modifies the sky shader and ash runner for testing. It requires 'Debug Printf' to be checked in the Vulkan Configuration app.
One important caveat is that using DebugPrintf seems to SEGFAULT (on Windows I get a (exit code: 0xc0000005, STATUS_ACCESS_VIOLATION)) the Vulkan program if you build a single module with multiple entry points. This is truely bizarre, no clue what's going on here. The only difference between working code and segfaulting code is this: expenses/rust-gpu@expenses:printf-not-working...printf-working.
At first I thought this was a driver issue but I'm getting this on both an integrated intel gpu and an external amd gpu.