01:59tiredchiku[d]: gfxstrand[d]: makes sense, thanks <3
02:05tiredchiku[d]: also re: windows port, how helpful would it be to first try and get nvk running on openrm on linux?
02:05redsheep[d]: I would think very
02:06redsheep[d]: I think there will be lots of overlap in those two efforts if we want to try to work towards the middle on it
02:06skeggsb9778[d]: also useful if nouveau/nova gain usermode submission someday 😛
02:06tiredchiku[d]: I imagine it'd also help accelerate our testing efforts, I know a fair few people who wanna try out nvk but have issues with nouveau kmd
02:07tiredchiku[d]: at least we'll be able to get more userspace testing out of it, and potentially be able to debug without wondering if it's a userspace bug or a kernel one
02:08redsheep[d]: I'm certain both an openrm port and a Windows port would help nouveau and nova kmds eventually too
02:09tiredchiku[d]: and testing would be easier for the less inclined folks, since it'd just be pointing to different icds to change drivers
02:09redsheep[d]: Because then we can have user space tested and known working and isolate things better for where the root causes are
02:09tiredchiku[d]: redsheep[d]: yup, exactly what's in my head
02:10tiredchiku[d]: I think an openrm implementation would be a good first stepping stone here
02:10tiredchiku[d]: since the openrm source is all there, making figuring out how to wire it up a tiny bit simpler
02:11tiredchiku[d]: if anything, it'll also help us test new GSP revisions more rapidly
02:17tiredchiku[d]: I wonder if there's any kind of roadmap to GSP ABI stability
02:17tiredchiku[d]: it would be nice to be able to manually swap out GSP revisions for testing them with nouveau/nova
04:22gfxstrand[d]: I doubt it. Nvidia wants the freedom to fix and improve the APIs between GSP and the kernel. Between GSP and userspace might be easier to stabilize, though.
04:25gfxstrand[d]: tiredchiku[d]: Yeah, I've had a number of people tell me they want to check out NVK but need CUDA. IDK if I want to fully support an openrm path but I'm starting to warm up to it a little.
04:55tiredchiku[d]: makes sense, yeah
04:56tiredchiku[d]: tho, is cuda a kernel side thing? does it actually need support from the kmod?
05:00tiredchiku[d]: I was under the impression that cuda is entirely a userspace problem, PTX to NIR stuff
05:00tiredchiku[d]: (I'm also among the CUDA crowd but I don't mind hopping between drivers to help out)
05:06asdqueerfromeu[d]: gfxstrand[d]: Does the Win32 KMD provide that information (or is it too hard to RE)?
09:11paul424: Parsing script Kobold.material
09:11paul424: Program 'myKoboldVertexShader' is not supported: 'Creature.vert' 0:9(1): error: #extension directive is not allowed in the middle of a shader
09:11paul424: Error: ScriptCompiler - invalid parameters in Kobold.material(10): Named constants have not been initialised, perhaps a compile error
09:11paul424: Error: ScriptCompiler - invalid parameters in Kobold.material(11): Named constants have not been initialised, perhaps a compile error
09:11paul424: Error: ScriptCompiler - invalid parameters in Kobold.material(12): Named constants have not been initialised, perhaps a compile error
09:12paul424: Error: ScriptCompiler - invalid parameters in Kobold.material(13): Named constants have not been initialised, perhaps a compile error
09:12paul424: the script compiler is too strict .
09:13paul424: The GLSL language for pixel and geometry shader . It keeps rejecting my pixel and vertex programs
09:13paul424: while the orignal nvidia driver accepts it
09:20HdkR: It's the alternative problem, the NVIDIA driver isn't strict enough to be compliant to the spec wording
09:21HdkR: So your shaders aren't compliant to the spec and the NVIDIA blob allows it :)
09:23paul424: mabye yes
09:24HdkR: Definitely yes if you have the #extension directive nine lines in with something before it
09:24paul424: https://github.com/tomluchowski/OpenDungeonsPlus/blob/shaders-improvement/shaders/Creature.vert
09:24paul424: it;s just after version
09:25paul424: I think that's fair
09:27paul424: HdkR, ? ...
09:27paul424: please please repair that
09:28HdkR: :thonk:
09:29HdkR: Could it be a line-endings problem?
09:30paul424: donno those were editied all the time under Linux
09:30paul424: file Creature.vert
09:30paul424: Creature.vert: C source, ASCII text
09:32paul424: if it were DOS endings , it would be : testfile2.txt: ASCII text, with CRLF line terminators
09:36paul424: HdkR, so Santa, could something be done ?
09:45mohamexiety[d]: tiredchiku[d]: part of it is the user side submissions and such that skeggsb and others mention yeah
09:47HdkR: paul424: Concern now would be Ogre gluing data on to the shader
09:48HdkR: an apitrace to see the raw string passed through glShaderSource would probably uncover something interesting
10:05paul424: and of course it is me who should in the end look at those apitraces...
10:09tiredchiku[d]: mohamexiety[d]: I see, thanks
10:22paul424: HdkR, so what could be done about that ? Or maybe it's not worth , cause the docs says on Kepler the pixel and vertex shaders are SLOW in the first place, because of the power managment issues
11:13magic_rb[d]: The end game of cross platform gamedev. You write your game using opengl, translate to vulkan using zink, and ship mesa for windows and linux with nvidia, intel and amd drivers
11:24asdqueerfromeu[d]: magic_rb[d]: The X-Plane™️ way ✈️
14:34karolherbst[d]: gfxstrand[d]: ohh, I know what's going on
14:35karolherbst[d]: I'll leave a reply
14:41karolherbst[d]: tldr: `char` is weird
14:47gfxstrand[d]: asdqueerfromeu[d]: Win32 provides some of it through standard interfaces but the adapter info struct is gonna be annoying to RE
14:49gfxstrand[d]: karolherbst[d]: I wondered about that...
14:51gfxstrand[d]: Stupid C...
14:57karolherbst[d]: yeah...
14:57karolherbst[d]: I ran into the same issue at some point
14:57gfxstrand[d]: paul424: We have a driconf flag for that. Try with `allow_glsl_extension_directive_midshader=true`
14:57gfxstrand[d]: If maybe it's =1, I can't remember
15:00gfxstrand[d]: Ideally, the app and its shaders would be fixed since it's open-source. But IDK how much the devs care.
15:03asdqueerfromeu[d]: gfxstrand[d]: ~~`nvidia_glsl` driconf when?~~
15:08gfxstrand[d]: https://tenor.com/view/tongue-out-disney-lilo-and-stitch-lilo-tease-gif-16079475
15:34gfxstrand[d]: At times in the past we've talked about being more lax and Nvidia-compatible but we tend to prefer correctness in Mesa land. Also, there are CTS tests for a bunch of this stuff. I don't knit how Nvidia passes. They probably have a "strict mode" flag they turn on just for the CTS.
15:48blockofalumite[d]: karolherbst[d]: What is char doing 👀
15:53gfxstrand[d]: Not being signed the way you'd think
15:53karolherbst[d]: yeah, it's implementation defined for weird reasons, and for reasons it's different on x86 and arm
15:59blockofalumite[d]: Ah, yea that makes sense
15:59blockofalumite[d]: I was kinda half hoping that someone hit the fact that char doesn't have to be 8 bits but signing fun is also fun
15:59karolherbst[d]: oh yeah, there is that as well
16:00karolherbst[d]: but that's true for all those C int types and on the rust side one should use the `c_*` types for them
17:13blockofalumite[d]: karolherbst[d]: Wait, how do you deal with them being variable size on the Rust side
17:14blockofalumite[d]: Also there's two c_char s qwq
17:15blockofalumite[d]: And it seems to be
17:15blockofalumite[d]: ```rs
17:15blockofalumite[d]: pub type c_char = i8;
17:15blockofalumite[d]: Which is quite wrong, huh
17:16blockofalumite[d]: Does Rust somehow re-assign those type definitions sometimes ?
17:18karolherbst[d]: blockofalumite[d]: you use the `c_*` types
17:18blockofalumite[d]: Yea, but *how* do you use them ?
17:19karolherbst[d]: blockofalumite[d]: they are platform dependent
17:19blockofalumite[d]: Which platform is https://doc.rust-lang.org/std/ffi/type.c_int.html from ?
17:20karolherbst[d]: x86 probably
17:20karolherbst[d]: but it's i32 of anything useful
17:22karolherbst[d]: mhh, looks like it's aarch64
17:24karolherbst[d]: anyway... it depends on the triple/target used when compiling
17:24karolherbst[d]: it might make some from/into calls a bit annoying to deal with, but you can have platform specific code if you really need to
17:24karolherbst[d]: but casting is usually good enough, because it's about c strings afterall
18:34blockofalumite[d]: karolherbst[d]: Wait, it's about C strings ?
18:36karolherbst[d]: yes
19:09blockofalumite[d]: karolherbst[d]: So uh, what does one use if they *don't* care about C strings ? This is confusing haha
19:09blockofalumite[d]: You can't just do an `as` cast as that'd fail on some platforms can you ?
19:09karolherbst[d]: if you don't care about C strings you won't write any code using c_char in the first place
19:10karolherbst[d]: and `as` won't fail, because it's about pointer casts here or casts between integer types which always compile
20:45blockofalumite[d]: karolherbst[d]: ? Why
22:17snektron[d]: blockofalumite[d]: usually you'd use one of the rust types for strings. Even if you're dealing with C strings I think there are types for that which are more intelligent than just a pointer or slice to chars, for example `OsString`
22:19blockofalumite[d]: snektron[d]: I am confused. I am talking about char, not about strings.
22:19blockofalumite[d]: C's char has nothing to do with strings
22:21snektron[d]: Ah sorry. It depends on what you want to do: If you want to represent a codepoint, you can use `char`. If you want to represent a byte its usually `u8`, unless you want it signed, in which case its `i8`
23:17gfxstrand[d]: Generally, you'll only use any of those types when communicating with C in which case, my usual approach is to just run bindgen and use whatever type it gives you. That or just use the `ffi::c_*` type associated with the C type. If you can change the c code, using `*intN_t` everywhere will give you normal rust types when you bindgen and is generally a good idea, IMO.
23:18blockofalumite[d]: snektron[d]: Byte here meaning ?
23:19snektron[d]: Smallest addressable type, I don't think there's a single platform that Rust can target where u8 is not a byte
23:20blockofalumite[d]: snektron[d]: So, we work around the issue of UB just by defining Rust to shit the bed on such systems 🤣 ?
23:21gfxstrand[d]: No, we do it be deciding we no longer care about writing new code on the Apollo guidance computers.
23:24gfxstrand[d]: As far as I'm aware, there is no interesting hardware being produced today or for most of the last half century that doesn't use an 8-bit byte. So you can say "OMG! We need to maintain this thorny corner of the language just in case" or you can say "we just won't support ancient, esoteric hardware with the new language we're designing in 2015"
23:26gfxstrand[d]: Rust also doesn't support 8-bit pointers. They draw the line at 16.
23:28clangcat[d]: gfxstrand[d]: To be fair it doesn't discount the future of computing being weird. But at that point I'd imagine things would just change as things change.
23:28clangcat[d]: As for the other point Rust just probably isn't the language if you (are/need to be) working in weird corner cases. Atleast not standard Rust.
23:29blockofalumite[d]: gfxstrand[d]: Reminder that even on x86, a C compiler with 9-bit chars is compliant
23:30clangcat[d]: blockofalumite[d]: Compliant with C spec yea. But super unlikely.
23:31gfxstrand[d]: Yeah, the future of computing may be weird but there's no reason to think it will be weird in that particular way. And if it is, Rust not having a char type isn't going to be the biggest problem. It's going to be all the C code we've written in the last 50 years that assumes char = int8 and is impossible to audit, not rust.
23:32blockofalumite[d]: clangcat[d]: We were considering writing a C compiler whose point is violating implementation defined or undefined invariants
23:32gfxstrand[d]: No one was doing that
23:33clangcat[d]: blockofalumite[d]: It would be kinda funny to have one that is just annoying but no one will support it.
23:34blockofalumite[d]: clangcat[d]: A lot of folks write portable C code; It'll be a good test suite.
23:34karolherbst[d]: they write portable C code for the architectures people use
23:34clangcat[d]: gfxstrand[d]: I think Ity is talking about themselves.
23:34karolherbst[d]: but if it's a 10 bit == byte archs, nobody will care enough if there are 10 users in the world of such an arch
23:35karolherbst[d]: even if they care about portability
23:35karolherbst[d]: they simply don't care all that much
23:35karolherbst[d]: so yeah, sure, having a compiler being completely weird is one idea, but iv you run on 80% of all computers - 10 that's fine
23:35blockofalumite[d]: clangcat[d]: Ity is not here right now 😅
23:36blockofalumite[d]: Oh right. We set our username here
23:36karolherbst[d]: It's a funky idea nonetheless
23:36blockofalumite[d]: karolherbst[d]: You haven't seen spec lawyers ahah
23:36karolherbst[d]: not the C spec
23:36clangcat[d]: karolherbst[d]: Yea it's funky but no one would go out of there way to support it
23:36clangcat[d]: Well no
23:36clangcat[d]: People interested in it would
23:37karolherbst[d]: yeah.. if you want your arch to be used, not doing crazy shit is one way to make people more likely to use your arch 😄
23:37clangcat[d]: But I doubt big projects like Rust dev team would care
23:37karolherbst[d]: they'd have to get LLVM to care first
23:37gfxstrand[d]: Rust doesn't care about the C spec.
23:37blockofalumite[d]: karolherbst[d]: It's about writing code targeting the C abstract machinr
23:38karolherbst[d]: which.. if you create a super weird arch today, would be your number 1 concern to make sure there will be an LLVM target for
23:38karolherbst[d]: oh sure, but that also includes having weird pointer things or other none sense stuff
23:38karolherbst[d]: though rust does care about tagged pointers, so there is that
23:38clangcat[d]: karolherbst[d]: Yea I mean you can make a custom one ut then it's getting it merged which would be an uphill battle
23:39karolherbst[d]: yeah
23:39karolherbst[d]: anyway, bindgen/rust abstract all the C stuff away in a good enough fashion, so there is that
23:39blockofalumite[d]: gfxstrand[d]: So the C FFI is just... Relying on UB or IB?
23:40karolherbst[d]: it's just annoying running into those weird issues
23:40karolherbst[d]: blockofalumite[d]: the ffi is target specific
23:40gfxstrand[d]: blockofalumite[d]: FFI is any target ABI, not C.
23:40blockofalumite[d]: Yes, and as I said, an x86 C compiler can have 9 bit bytes
23:41karolherbst[d]: the problem is.. you need a libc to throw it at
23:41karolherbst[d]: and without a libc the target ain't really relevant
23:41karolherbst[d]: and for mesa, targets not supporting GPUs are even less relevant
23:41gfxstrand[d]: You can write an x86 compiler with a 9-bit char but if you want to target the linux-gnu-x86 ABI, you'll have power-of-two types everywhere.
23:42blockofalumite[d]: gfxstrand[d]: Integer-extend
23:42blockofalumite[d]: And yea I suppose can also do 64bit chars
23:42gfxstrand[d]: And if you ever share a header and try to link with something compiled with GCC or clang, you're in for a world of hurt if your char isn't the same.
23:43karolherbst[d]: blockofalumite[d]: I can install PK if you want to 😄
23:43blockofalumite[d]: Or various other funsies
23:43blockofalumite[d]: karolherbst[d]: Please do
23:43blockofalumite[d]: 🙏
23:44blockofalumite[d]: Though unsure if we will hang out here from tomorrow, there's a reason ity isn't fronting rn haha. It isn't really anything doing anything wrong, just memories surfacing and ya.
23:45blockofalumite[d]: (We wish that oftc.net would start working again though)
23:46gfxstrand[d]: Yeah, those two make sense. It's a little annoying that `usize` doesn't implement `From<u32>`, though.
23:51gfxstrand[d]: And AVR and MSP430 are chips people actually care about and where rust is actually probably pretty dang useful.
23:52gfxstrand[d]: Rust's vicious love of putting everything on the stack is really nice in the embedded world.