15:34fdobridge: <gfxstrand> Why do these tests pass when run together but fail when run separately?!? 🤯
16:01fdobridge: <gfxstrand> Oh, well this is fun... Source modifiers work differently on IAdd3 in X mode
16:01fdobridge: <gfxstrand> I think I want a separate opcode, maybe?
16:02fdobridge: <karolherbst🐧🦀> huh?
16:02fdobridge: <karolherbst🐧🦀> in what way?
16:02fdobridge: <karolherbst🐧🦀> there is a restriction on `IADD3` btw on source modifiers
16:02fdobridge: <gfxstrand> abs gets ignored and - becomes ~
16:02fdobridge: <karolherbst🐧🦀> like generally
16:03fdobridge: <karolherbst🐧🦀> ahh yeah
16:03fdobridge: <karolherbst🐧🦀> `-` desn't exist on IADD3.X apparently 😄
16:03fdobridge: <karolherbst🐧🦀> anyway, I can confirm this
16:05fdobridge: <karolherbst🐧🦀> @gfxstrand this seems to be the case for all `.X` variants
16:05fdobridge: <gfxstrand> I'm going to add a separate IAddX opcode
16:06fdobridge: <karolherbst🐧🦀> you'll also need it for IMAD and IMUL
16:06fdobridge: <gfxstrand> abs doesn't exist because integers
16:06fdobridge: <gfxstrand> Why? Do they have an X mode?
16:06fdobridge: <karolherbst🐧🦀> yeah
16:06fdobridge: <gfxstrand> What does it do?
16:06fdobridge: <karolherbst🐧🦀> and `LEA` as well
16:06fdobridge: <karolherbst🐧🦀> also known as `ISCADD`
16:07fdobridge: <karolherbst🐧🦀> uhm..
16:07fdobridge: <karolherbst🐧🦀> it's just IMAD actually
16:07fdobridge: <karolherbst🐧🦀> IMUL is the same as IMAD anyway, but...
16:07fdobridge: <karolherbst🐧🦀> so it's for the ADD part of IMAD
16:08fdobridge: <karolherbst🐧🦀> and applies to the last arg
16:08fdobridge: <gfxstrand> Oh
16:08fdobridge: <gfxstrand> Makes some sense, I guess. I'll add it if I need it.
16:08fdobridge: <karolherbst🐧🦀> some for `ISCADD` obviously
16:08fdobridge: <karolherbst🐧🦀> *Same
16:09fdobridge: <karolherbst🐧🦀> heh.. `ISCADD` has a `.SX32` modifier...
16:10fdobridge: <karolherbst🐧🦀> do not fully understand what it does though
16:11fdobridge: <karolherbst🐧🦀> kinda replaces the last arg with the sign of the first one I think
16:28quantum`: Hi, is 3D for video working?
16:29karolherbst: quantum`: what do you mean by that?
16:29quantum`: I want to watch 3D movies, but with the nvidia driver the stream is not recognized by the projector as such.
16:31karolherbst: mhhh.. good question. I think some people have worked on it, but I have no idea if that even works
16:35quantum`: Here https://nouveau.freedesktop.org/ it says it is, but the last update was Jan, 2021.
16:37karolherbst: huh? that's a different 3D
16:38quantum`: How so?
16:38karolherbst: and yeah.. we should update the wiki a bit
16:38karolherbst: well.. do you mean 3D rendering? or 3D movies?
16:38quantum`: Isn't 3D... 3D?
16:38karolherbst: like 3D movies as in stereo visuals
16:39quantum`: Stereo visuals are my interest.
16:39karolherbst: well.... no, 3D movies are osmething entirely different then e.g. playing 3D games
16:39karolherbst: yeah.. stereo visuals should work, but we don't have a lot of users actually trying that
16:39karolherbst: but there is code for stereo support
16:40quantum`: K, I'll try it. Any special instructions? mesa?
16:40karolherbst: mhh, no idea. I never tried myself as I don't have the hardware
16:40karolherbst: for stereo visuals that is
16:41karolherbst: but yeah.. mesa is the opengl driver at least and it's kinda required for 2D acceleration with e.g. the modesetting DDX or wayland compositors
16:54quantum`: Ty
19:49fdobridge: <gfxstrand> Like what? Some negates aren't working and that appears to be my problem.
19:50fdobridge: <karolherbst🐧🦀> you can only have one modifier on the first two sources
19:51fdobridge: <gfxstrand> Okay, I don't seem to be violating that...
19:51fdobridge: <gfxstrand> I do have one with - on both src1 and src2 but not src0
19:52fdobridge: <karolherbst🐧🦀> mhh yeah, that should be fine
19:52fdobridge: <karolherbst🐧🦀> any specific one which doesn't work?
19:52fdobridge: <gfxstrand> I'm still working on narrowing it down
19:52fdobridge: <karolherbst🐧🦀> though uhhh
19:52fdobridge: <karolherbst🐧🦀> I think IADD also has a different ordering of sources..
19:53fdobridge: <karolherbst🐧🦀> mhh, maybe it was a different instruction
19:53fdobridge: <karolherbst🐧🦀> or maybe it does...
19:54fdobridge: <karolherbst🐧🦀> ehh should be fine
19:54fdobridge: <karolherbst🐧🦀> might be something on an older gen...
19:55fdobridge: <karolherbst🐧🦀> does nvdisasm complain about your encoding?
19:56fdobridge: <karolherbst🐧🦀> anyway, that's the only restriction I know it's documented (only one negate on the first two sources)
19:56fdobridge: <gfxstrand> No, nvdisasm doesn't complain
19:57fdobridge: <karolherbst🐧🦀> mhhh
19:57fdobridge: <karolherbst🐧🦀> another option is always scheduling, but I think you still have the default value, right?
19:57fdobridge: <gfxstrand> Yeah, it's not scheduling
19:58fdobridge: <gfxstrand> I really need to write an opcode fuzzer so I can RE exact behavior on these things.
19:58fdobridge: <karolherbst🐧🦀> yeah...
19:59fdobridge: <gfxstrand> It seems to be like you can only have - on the last non-zero source or something
19:59fdobridge: <karolherbst🐧🦀> maybe something with the predicates?
19:59fdobridge: <karolherbst🐧🦀> IADD3 has a bunch of those
19:59fdobridge: <gfxstrand> I *think* my predicates are fine
19:59fdobridge: <karolherbst🐧🦀> are you emitting five of them? 😄
20:00fdobridge: <gfxstrand> But I honestly don't know because I don't have a good way to fuzz stuff
20:00fdobridge: <gfxstrand> I'm emitting 4
20:00fdobridge: <gfxstrand> 5 if you include the whole-inst predicate
20:00fdobridge: <karolherbst🐧🦀> yeah
20:00fdobridge: <karolherbst🐧🦀> mhh
20:00fdobridge: <gfxstrand> I would also really love to know what they all do.
20:00fdobridge: <gfxstrand> 😂
20:00fdobridge: <karolherbst🐧🦀> two carries
20:00fdobridge: <karolherbst🐧🦀> input/output
20:01fdobridge: <gfxstrand> Are the outputs the same or is one of them signed?
20:01fdobridge: <karolherbst🐧🦀> signed?
20:02fdobridge: <karolherbst🐧🦀> they appear to be equal, I suspect they just match the first and second internal addition operation
20:02fdobridge: <gfxstrand> I have a feeling that if I can actually figure out how all the little bits and bobs on IADD3.X work, I should be able to implement isub64 in one op
20:02fdobridge: <gfxstrand> two ops, rather
20:02fdobridge: <karolherbst🐧🦀> mhh
20:02fdobridge: <gfxstrand> Oh, that could be...
20:02fdobridge: <gfxstrand> In that case, does switching arguments around affect which predicates you want to use?
20:02fdobridge: <gfxstrand> If so, 🤯
20:02fdobridge: <karolherbst🐧🦀> uhhh
20:02fdobridge: <karolherbst🐧🦀> maybe?
20:04fdobridge: <karolherbst🐧🦀> okay... soo
20:04fdobridge: <karolherbst🐧🦀> the second input/output predicates aren't used in the `IADD` version
20:04fdobridge: <karolherbst🐧🦀> so I suspect they match the second addition
20:05fdobridge: <gfxstrand> That would make sense
20:05fdobridge: <gfxstrand> This is why I need a fuzzer....
20:05fdobridge: <karolherbst🐧🦀> fun part
20:05fdobridge: <karolherbst🐧🦀> input defaults to false where output defaults to true
20:05fdobridge: <gfxstrand> ?
20:06fdobridge: <karolherbst🐧🦀> so if you implement `IADD` on top of `IADD3` the second input predicate needs to be `!PT` where the second output predicate will have to be `PT`, but I think that's just internal nonsense
20:06fdobridge: <gfxstrand> Oh, outputs don't have ! so PT is just a null destination
20:06fdobridge: <gfxstrand> That's fine
20:07fdobridge: <karolherbst🐧🦀> yeah..
20:07fdobridge: <gfxstrand> And !PT is zero
20:07fdobridge: <karolherbst🐧🦀> I'm just curious because it's explicitly mentioned
20:07fdobridge: <karolherbst🐧🦀> but I think that's just docmentation on how the assembler works
20:07fdobridge: <karolherbst🐧🦀> anyway
20:07fdobridge: <karolherbst🐧🦀> the ISA doc also specifies how to implement a 64 bit addition in two ops 😄
20:07fdobridge: <gfxstrand> Okay, yeah, I'm buying your 1st and 2nd addition theory.
20:08fdobridge: <gfxstrand> That one's pretty obvious. It's subtract that's tricky.
20:08fdobridge: <karolherbst🐧🦀> and also substract
20:08fdobridge: <karolherbst🐧🦀> ohhhh
20:08fdobridge: <gfxstrand> What does it say for subtract? That might give me some clues
20:08fdobridge: <karolherbst🐧🦀> yeah..
20:08fdobridge: <karolherbst🐧🦀> I can tell you or you want to figure it out? 😄
20:11fdobridge: <karolherbst🐧🦀> iadd dst0.lo, p0, ra.lo, -rb.lo
20:11fdobridge: <karolherbst🐧🦀> iadd.x dst0.hi, !pt, ra.hi, ~rb.hi, p0
20:12fdobridge: <karolherbst🐧🦀> .X is just for consuming the carry predicate in case you didn't know
20:12fdobridge: <gfxstrand> Yes but it also changes - to ~
20:12fdobridge: <gfxstrand> Which is an important little distinction
20:12fdobridge: <gfxstrand> And it's why sub works
20:12fdobridge: <karolherbst🐧🦀> yeah
20:14fdobridge: <karolherbst🐧🦀> anyway, I hope that helps
20:14fdobridge: <gfxstrand> Some, yeah. I still feel like I need to fuzz this dizzy little thing to figure out more exact semantics.
20:14fdobridge: <gfxstrand> Especially around why - isn't working in misc. places.
20:14fdobridge: <karolherbst🐧🦀> mhhh
20:14fdobridge: <karolherbst🐧🦀> yeah dunno
20:15fdobridge: <karolherbst🐧🦀> all I know is, that one restriction
20:16fdobridge: <gfxstrand> I think I'm going to write an opcode fuzzer. I just need to figure out what I want it to look like.
20:17fdobridge: <karolherbst🐧🦀> write an shader emulator and....
20:17fdobridge: <gfxstrand> Launching compute shaders is easy enough that I'm almost tempted to hand-code that.
20:17fdobridge: <gfxstrand> A shader emulator doesn't help if I don't know what I'm emulating.
20:17fdobridge: <karolherbst🐧🦀> I kinda meant like the mme stuff
20:17fdobridge: <karolherbst🐧🦀> but yeah...