00:22fdobridge: <gfxstrand> Okay, I've run 1k fuzzing tests through it. I think my layouts are good
00:42fdobridge: <gfxstrand> Now to figure out how to do 2D array views of 3D without smashing tiling.z_log2 to 0
00:43fdobridge: <karolherbst🐧🦀> I'm not sure that's possible at all?
00:43fdobridge: <gfxstrand> It's got to be
00:43fdobridge: <gfxstrand> Sparse requires it
00:43fdobridge: <karolherbst🐧🦀> why?
00:43fdobridge: <karolherbst🐧🦀> uhhh
00:43fdobridge: <karolherbst🐧🦀> and I thought vulkan had this bit to state that you are going to do this kinda of stuff
00:44fdobridge: <gfxstrand> Yeah but Vulkan also has standard block sizes which have a different opinion
00:44fdobridge: <karolherbst🐧🦀> but if sparse is special here.. then mhh..
00:44fdobridge: <gfxstrand> I think we can do it on Maxwell+
00:44fdobridge: <karolherbst🐧🦀> maybe?
03:46fdobridge: <gfxstrand> Yeah, it's looking like we can't. Fortunately, there's a VU for it
03:47fdobridge: <gfxstrand> We do have to support 2D views of 3D, just not 2D array views.
03:49fdobridge: <gfxstrand> I think that's okay, though. That *should* just be a 3D view that we access with a 2D sampler. At least I'm hoping as much.
04:43fdobridge: <gfxstrand> That seems to work except now I have to figure out sliced_view_of_3d
04:43fdobridge: <gfxstrand> Annoyingly, that one doesn't have an image create bit
04:45fdobridge: <gfxstrand> But also that's part of D3D12 so I *know* the hardware can do it. I just need to figure out how.
04:45fdobridge: <gfxstrand> Hell.... there's an idea....
04:46fdobridge: <gfxstrand> Why didn't I think of this before...
04:46fdobridge: <gfxstrand> If I write a little bit of D3D code, I can get NVIDIA's blob driver to cough out fully baked texture headers...
04:47fdobridge: <gfxstrand> 😈
04:47fdobridge: <Sid> 👀
04:49fdobridge: <gfxstrand> I need to chat with @themaister about this
05:13fdobridge: <redsheep> Would that code need to get ran on windows to go straight to the blob's native directx driver? Let me know if there's anything I can help capture, if you don't have a windows install
05:31fdobridge: <airlied> @gfxstrand can't you just use a CTS test on the prop driver
05:34fdobridge: <Sid> does anyone know how to build and boot a debug kernel on arch
05:34fdobridge: <Sid> I need to run faddr2line
05:34fdobridge: <Sid> but the final bzimage that's being built is always stripped of debug symbols
05:46fdobridge: <gfxstrand> I can but that involves fishing it out of memory. With D3D12, I can just give it a pointer and say "put the descriptor here, please"
07:16fdobridge: <tom3026> @redsheep are you on kde/kwin?
07:17fdobridge: <redsheep> Yes
07:19fdobridge: <tom3026> @redsheep if on wayland https://invent.kde.org/plasma/kwin/-/commit/be9d2fd7d07b84f0a9be7d950947ea097011356f 6.0.1 kinda fixed https://invent.kde.org/plasma/kwin/-/commit/456ed767e6ce30e87829fa11e86cab6586bae7aa two major things
07:20fdobridge: <tom3026> so you dont blame nouveau for frameskips and stutters! 😄
07:22fdobridge: <tom3026> show me your pkgbuild
07:22fdobridge: <tom3026> most of them manually strip files in the package function
07:22fdobridge: <redsheep> I've been testing on openbox as well to try to isolate my variables
07:22fdobridge: <tom3026> ah okay 👍
07:26fdobridge: <Sid> I removed all of that
07:26fdobridge: <Sid> and I got it sorted in the end
07:28fdobridge: <tom3026> okay heh
07:29fdobridge: <tom3026> i might not know gpu driver coding but ive been fiddling with half self built -git "Arch" from compiler to libc so got any questions ive probably been there at some point in the past 16 years. ask away! 😄
07:30fdobridge: <redsheep> These fixes do seem like they might explain my higher performance in talos, I realized that was along with it switching me to the wayland session without saying anything
07:30fdobridge: <redsheep> The x session is mostly the same performance. I feel like maybe kwin is responsible for the difference between installed vs not installed drivers
07:31fdobridge: <redsheep> In terms of performance, that is. That stuff is behaving really weirdly right now.
07:33fdobridge: <tom3026> i mean at what stage are the drivers linked/loaded when the first xwayland process is running or when the game runs? because kwin kinda launches it directly you log in
07:33fdobridge: <Sid> yeag plasma 6 wl does buffer latching correctly
07:33fdobridge: <Sid> compared to 5
07:33fdobridge: <tom3026> meaning you pretty much dont load that local driver whatever you do
07:34fdobridge: <tom3026> since most games is in xwayland anyhow, unless you get wine 9.x and force it to the wayland driver i guess heh
07:37fdobridge: <redsheep> Hmm testing proton games with it forced to wayland is an interesting idea. I don't think I will do too terribly much more performance testing until the modifiers situation is fixed though, I get the sense it's really messing things up not to have those.
07:39fdobridge: <tom3026> its quite easy once its compiled in, set the registry key so it "fallbacks" to wayland if $DISPLAY is unset, so anytime you wanna swap "DISPLAY= wine game.exe"
07:39fdobridge: <tom3026> not everything is implented yet so there is some breakage but most dxvk/vkd3d games i tried works
14:18fdobridge: <gfxstrand> @tiredchiku did you have a fix for suspend/resume somewhere?
14:25fdobridge: <Sid> here
14:25fdobridge: <Sid> https://github.com/torvalds/linux/commit/f6ecfdad359a01c7fd8a3bcfde3ef0acdf107e6e
14:29fdobridge: <gfxstrand> Thanks! I've been fighting suspend problems for a while and they seemed to be nouveau related. Here's hoping that helps.
14:30fdobridge: <Sid> 🤞
15:56fdobridge: <babblebones> Laptop enjoyers gonna have their day with this one ❤️
15:56fdobridge: <Sid> ?
15:57fdobridge: <Sid> oh that patch
15:57fdobridge: <Sid> yus, I ran into the issue on a laptop :p
16:16fdobridge: <zmike.> .
16:17magic_rb: fdobridge: Interesting, because of s2idle being the only available suspend i havent ran into this
16:18fdobridge: <Sid> magic_rb on laptops, gpus enter d3cold when there's no load
16:19fdobridge: <Sid> which is why I ran into it, almost immediately after boot
16:19fdobridge: <Sid> and the same suspend logic applies to desktop suspend as well
16:20magic_rb: Im on a laptop, but my laptop cannot enter s3
16:20magic_rb: Only s2idle with s0ix
16:20magic_rb: I do also wonder about the power ststes the proprietary driver exposes, it uses P0-P8 iirc
16:37fdobridge: <gfxstrand> @karolherbst For SSY and SYNC on Maxwell, is there some sort of internal stack or something?
16:37fdobridge: <karolherbst🐧🦀> correct, and it's fixed in size, and if you run out of stack you can allocate it as part of tls
16:37fdobridge: <karolherbst🐧🦀> like there is a field in the SPH for it
16:37fdobridge: <karolherbst🐧🦀> c/r stack is the term
16:37fdobridge: <gfxstrand> And SSY spills to that?
16:38fdobridge: <karolherbst🐧🦀> any instruction branching does, it's like the barrier registers, just transparent to the shader
16:38fdobridge: <karolherbst🐧🦀> ehh.. not branching
16:38fdobridge: <karolherbst🐧🦀> like.. those who affect the thread masks in weird ways
16:39fdobridge: <karolherbst🐧🦀> those loop CFG ones as well
16:39fdobridge: <karolherbst🐧🦀> any one where you push to it implicitly, in codegen we call those prebreak/break, etc...
16:41fdobridge: <gfxstrand> Ugh... this feels annoyingly intelish. 😅
16:43fdobridge: <karolherbst🐧🦀> the thing is, the stack isn't even big
16:43fdobridge: <karolherbst🐧🦀> like 512 bytes or something?
16:43fdobridge: <karolherbst🐧🦀> but we also don't really know how it works
16:44fdobridge: <gfxstrand> No, the max is 1 MB
16:44fdobridge: <karolherbst🐧🦀> and you need to know ahead of time if you use the fixed sized one or the spilled one
16:44fdobridge: <karolherbst🐧🦀> naaah
16:44fdobridge: <karolherbst🐧🦀> if you set 0, you use a fast on chip one
16:44fdobridge: <karolherbst🐧🦀> but you need ti know ahead of time how much you need in the worst case
16:44fdobridge: <karolherbst🐧🦀> it's all a bit painful
16:45fdobridge: <karolherbst🐧🦀> I think you can configure the spilled on in steps of 512 bytes, but I think the non spilled one is also just 512 bytes in size.. maybe a bit bigger, never really could figure it out
16:46fdobridge: <karolherbst🐧🦀> it's a bit annoying that it's a all or nothing thing
16:47fdobridge: <gfxstrand> It doesn't look like nouveau actually programs that header bit at all
16:47fdobridge: <karolherbst🐧🦀> yeah... we only do it for compute
16:47fdobridge: <karolherbst🐧🦀> we had _one_ bug where we run out of space
16:48fdobridge: <karolherbst🐧🦀> and the corruption was pretty unimportant for game play
16:48fdobridge: <karolherbst🐧🦀> but for compute we do it unconditionally
16:49fdobridge: <karolherbst🐧🦀> `SHADER_LOCAL_MEMORY_CRS_SIZE` in the QMD
16:49fdobridge: <gfxstrand> nv4e_compute.c:171 would like to differ. 😛
16:50fdobridge: <gfxstrand> Oh, I see in CRS
16:50fdobridge: <gfxstrand> Oh, I see in the QMD (edited)
16:50fdobridge: <gfxstrand> Sure, just set it to a big fixed value and hope it's right. 😅
16:50fdobridge: <karolherbst🐧🦀> 🙂
16:50fdobridge: <karolherbst🐧🦀> as I said: we hit one bug on the 3D side and that's all
16:50fdobridge: <karolherbst🐧🦀> 😄
16:51fdobridge: <gfxstrand> Yeah, that's not gonna work for vk...
16:51fdobridge: <karolherbst🐧🦀> I know
16:52fdobridge: <karolherbst🐧🦀> however...
16:52fdobridge: <karolherbst🐧🦀> it's stored in the TLS buffer
16:52fdobridge: <karolherbst🐧🦀> so we could actually reverse engineer whtever happens
16:52fdobridge: <gfxstrand> Yeah
16:53fdobridge: <gfxstrand> In any case, the first step is to add the instructions
16:53fdobridge: <karolherbst🐧🦀> yeah
16:53fdobridge: <gfxstrand> And figuring out the stack depth shouldn't actually be that hard
16:53fdobridge: <gfxstrand> Thank you, NIR, for being structured. 😅
16:53fdobridge: <karolherbst🐧🦀> yeah...
16:53fdobridge: <karolherbst🐧🦀> when I was looking into the issue ......
16:54fdobridge: <karolherbst🐧🦀> but the shader hitting this was a nested loop thing and nvidia just loop merged the whole thing...
16:55fdobridge: <gfxstrand> I guess the first question is if I should do it in NIR or directly in nak_from_nir
16:55fdobridge: <pixelcluster> Quser Mode Driver? :P
16:57fdobridge: <gfxstrand> Now the real question: Do I want to make each one its own instruction with a mode or multiple?
16:57fdobridge: <gfxstrand> It's multiple in the HW
17:03fdobridge: <zmike.> @gfxstrand here you go, one item off your todo list https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28078
17:04fdobridge: <zmike.> and with that, I think my work here is done
17:05fdobridge: <gfxstrand> woo
17:24fdobridge: <!DodoNVK (she) 🇱🇹> Does SuperTuxKart work on zink + NVK now?
17:26fdobridge: <mhenning> @gfxstrand It's lso worth noting that SYNC acts as an actual control flow instruction eg. an if statement can be implemented as just an SSY beforehand + a conditional jump in the branches + a SYNC at the end of each of the branches (at least on kepler, where I was doing some RE a few years ago)
17:26fdobridge: <zmike.> https://www.supergoodcode.com/woof/
17:27fdobridge: <mhenning> codegen doesn't use it this way - it acts like it needs to do the reconvergence separately
17:29fdobridge: <mhenning> but anyway, there's a few annoying details in that a loop will take more control stack space depending on whether you need prebreak and precontinue entries
17:30fdobridge: <mhenning> codegen always inserts them and then deletes the precontinue if it isn't needed, which makes it harder to find out the actual stack size than if it were done in from_nir
17:31fdobridge: <mhenning> @gfxstrand It's lso worth noting that SYNC acts as an actual control flow instruction eg. an if statement can be implemented as just an SSY beforehand + a conditional jump to the branches + a SYNC at the end of each of the branches (at least on kepler, where I was doing some RE a few years ago) (edited)
17:32fdobridge: <gfxstrand> Neat!
17:34fdobridge: <redsheep> I've tested loads of games and haven't yet found one that isn't working. Sessions are still a little shaky though.
17:36fdobridge: <redsheep> Anybody have a non Nvidia card where they care to test zink running discord? It's not clear if the corrupting server icons is an NVK or zink bug
17:37fdobridge: <redsheep> Or are we at the point with zink+NVK where I should just open an issue for that?
17:38fdobridge: <conan_kudo> Welp. https://www.tomshardware.com/pc-components/gpus/nvidia-gtx-branding-finally-reaches-the-end-of-the-line-after-19-years-the-last-gtx-16-series-chips-have-left-the-foundry
17:39fdobridge: <redsheep> ... These were still being made huh? Weird.
17:39fdobridge: <rinlovesyou> i didn't even know it uses opengl
17:39fdobridge: <!DodoNVK (she) 🇱🇹> What's the corruption bug?
17:40fdobridge: <rinlovesyou> ```LIBGL_KOPPER_DRI2=1 __GLX_VENDOR_LIBRARY_NAME=mesa MESA_LOADER_DRIVER_OVERRIDE=zink GALLIUM_DRIVER=zink VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/nvidia_icd.json discord```
17:40fdobridge: <rinlovesyou>
17:40fdobridge: <rinlovesyou> ran it with the proprietary driver, turned on hardware acceleration in the discord settings, and i'm not seeing any server icons corrupting
17:40fdobridge: <redsheep> Hovering the server icons turns them cursed. Also screen share UI is similarly weird.
17:41fdobridge: <rinlovesyou> ```
17:41fdobridge: <rinlovesyou> [6979:0308/183854.948883:ERROR:gl_ozone_egl.cc(23)] GLDisplayEGL::Initialize failed.
17:41fdobridge: <rinlovesyou> [6979:0308/183854.950096:ERROR:viz_main_impl.cc(186)] Exiting GPU process due to errors during initialization
17:41fdobridge: <rinlovesyou> ```
17:41fdobridge: <rinlovesyou> oh well, it's certainly not working
17:41fdobridge: <!DodoNVK (she) 🇱🇹> Can't reproduce with RADV
17:42fdobridge: <!DodoNVK (she) 🇱🇹> What's up with this though?: `MESA: error: ZINK: failed to choose pdev`
17:42fdobridge: <redsheep> Good to know, so probably an NVK issue. Dunno if we're doing issues for this kind of thing yet.
17:44fdobridge: <zmike.> stop doing `GALLIUM_DRIVER=zink`
17:44fdobridge: <!DodoNVK (she) 🇱🇹> I did `MESA_LOADER_DRIVER_OVERRIDE=zink`
17:45fdobridge: <zmike.> it was a general statement
17:45magic_rb: Whats the correct way to make zink run?
17:45fdobridge: <redsheep> I've been using NOUVEAU_USE_ZINK lately
17:45fdobridge: <!DodoNVK (she) 🇱🇹> I think that's NVK-specific though
17:46magic_rb: Im considering setting it session global, it seems to be the path forward, so might as well test it out early
17:47fdobridge: <redsheep> If you try Wayland and it fails x11 will probably be fine, of not ideal
17:47fdobridge: <redsheep> if*
17:48magic_rb: Im still on x11 because of xmonad and until recently being on proprietary nvidia
17:48magic_rb: So wayland is not a concern i have yet
17:51fdobridge: <redsheep> Oh also depending what you mean by session global it may or may not run the session itself. I've been putting NOUVEAU_USE_ZINK=1 in /etc/environment
17:52magic_rb: Either eight after xmonad starts or before it starts
17:53fdobridge: <gfxstrand> Okay, down to two sparse bugs:
17:53fdobridge: <gfxstrand> 1. The CTS gets confused that we advertise `R10X6` and `R10X6G10X6` formats. Arguably, this is a CTS bug but I don't know that I care that much.
17:53fdobridge: <gfxstrand> 2. We need to make the stencil_copy_temp part of the miptail somehow
17:54fdobridge: <zmike.> did you run any of the glcts sparse tests yet
17:55fdobridge: <gfxstrand> No
17:56fdobridge: <zmike.> you're in for a good time.
17:57fdobridge: <mhenning> Okay, I found my notes from REing control flow stuff on kepler. Another detail: the case where a conditional branch is taken executes first. This means that else branches of ifs (at least in codegen's impl) take one stack entry more than the "then" branch. So, including the SSY, a divergent branch consumes two stack slots on the "else" branch and one stack slot on the "then" branch
17:57fdobridge: <mhenning> I also wrote down "Allocate 512 + 512 * (stack_depth / 32) bytes (round up)" for the size of the control flow stack on kepler. Note that this is different from an expression I found elsewhere, so there's something I don't understand going on - the size of the on-chip stack might vary by generation
18:01fdobridge: <waelunix> ok so after a painful weekend, i finally have MESA 24.1.0 dev working with NVK
18:02fdobridge: <waelunix> zink on NVK seems to be working **iff* i have gallium nouveau as well
18:02fdobridge: <waelunix> zink on NVK seems to be working **iff** i have gallium nouveau as well (edited)
18:02fdobridge: <waelunix> otherwise i can't run any wayland compositor due to missing DRI3
18:03fdobridge: <zmike.> `LIBGL_KOPPER_DRI2=1`
18:04fdobridge: <!DodoNVK (she) 🇱🇹> So does Kopper not support DRI3?
18:06fdobridge: <waelunix> Would that work with `MESA_LOADER_DRIVER_OVERRIDE=zink NOUVEAU_USE_ZINK=yes`? cause it doesn't work when I have gallium nouveau
18:06fdobridge: <waelunix> and i'm not looking forward to ~~compiling mesa again~~ switching back to an older generation
18:08fdobridge: <redsheep> You don't need both of those variables to force on zink, and I don't think yes is valid input, I've been doing 1
18:09fdobridge: <zmike.> probably
18:09fdobridge: <waelunix> So i tried running sway with the above incantation. It's complaining about `EGL_EXT_image_dma_buf` not being implemented and just dies
18:09fdobridge: <zmike.> and both of those is redundant
18:09fdobridge: <zmike.> nvk doesn't
18:09fdobridge: <zmike.> yes, that's dri3
18:10fdobridge: <waelunix> Is there any wayland compositor that's DRI2 compatible 🥺
18:10fdobridge: <!DodoNVK (she) 🇱🇹> @ gfxstrand 👀
18:10fdobridge: <zmike.> you mean software
18:10fdobridge: <zmike.> and yes, weston
18:11fdobridge: <zmike.> you don't need to ping anyone about this, it's being discussed constantly here every day
18:12fdobridge: <waelunix> Weston doesn't work and is complaining about DRM atomic modesetting not being implemented
18:12fdobridge: <waelunix> I'm guessing even with `LIBGL_KOPPER_DRI2=1 ` i'm somehow not getting any DRI ?
18:12fdobridge: <waelunix> I'm guessing even with `LIBGL_KOPPER_DRI2=1` i'm somehow not getting any DRI ? (edited)
18:12fdobridge: <zmike.> use uhh
18:13fdobridge: <zmike.> it's like `WESTON_NO_ATOMIC=1` or something
18:13fdobridge: <zmike.> WESTON_DISABLE_ATOMIC
18:15fdobridge: <waelunix> Good news? It's not complaining about DRI anymore. Now i just have to deal with regular seat weirdness. _of to the arch wiki i go_
18:15fdobridge: <waelunix> Good news? It's not complaining about DRI anymore. Now i just have to deal with regular seat weirdness. _of fto the arch wiki i go_ (edited)
18:15fdobridge: <waelunix> Good news? It's not complaining about DRI anymore. Now i just have to deal with regular seat weirdness. _off to the arch wiki i go_ (edited)
18:25fdobridge: <waelunix> ok so that didn't work. It "starts" but the fb still shows the PTY
18:28fdobridge: <waelunix> Sorry for not checking more throughly beforehand orz
18:28fdobridge: <waelunix> https://gitlab.freedesktop.org/mesa/mesa/-/issues/10477
19:05magic_rb: running minecraft using this wrapper command "gamescope -w 2560 -h 1600 -r 60 -o 60 -f -- sh -c 'DRI_PRIME=1 NOUVEAU_USE_ZINK=1 "$@"' sh" creates a work of art and not a menu screen, without gamescope it works, i assume its because im not running gamescope on the same gpu as im running the game
19:08fdobridge: <zmike.> probably the same issue
19:41Lyude: TimurTabi: btw, looks like 042b5f83841fbf frees a bunch of boot/init buffers - but unfortunately we still need those for runtime PM (I haven't checked, but it's probably also needed for S3/S4) so it seems that commit breaks runpm on this machine. gonna send a patch out in a moment
19:47Lyude: oh, lol, seems like someone already fixed that
19:47Lyude: do you need someone to push the patch?
19:48fdobridge: <tom3026> its landed, 6.7.9 or 6.8 :p
19:50fdobridge: <Sid> yup
19:50fdobridge: <Sid> 6.7.9 and 6.8-rc7
19:53Lyude: oh huh, this was off a drm-next kernel
19:53Lyude: maybe I switched to the wrong branch by mistake
19:53Lyude: (unless you meant a different issue Sid?)
19:53Sid127: nope, same issue
19:54Lyude: gotcha
19:54Lyude: well good to know that's handled :)
19:54Sid127: <3
19:59fdobridge: <gfxstrand> Okay, now the next question: How do the different sync things nest?
20:00fdobridge: <gfxstrand> Does each thing pop one sync or does break/cont pop all the syncs?
20:02fdobridge: <gfxstrand> If it works anything like Intel, there's a precedence order: break > cont > sync
20:02TimurTabi: Lyude: I think drm-next needs to be rebased.
20:03fdobridge: <karolherbst🐧🦀> there is some of it, but I think sync is special... but also not sure
20:03fdobridge: <gfxstrand> I don't suppose you have docs on any of this?
20:03fdobridge: <karolherbst🐧🦀> I don't 🙂
21:15fdobridge: <gfxstrand> @airlied Any progress on the IRQ issue? Thanks to the map fix, I can now complete a run about 50% of the time. The other 50% the card goes out to lunch.
21:23fdobridge: <airlied> nah travel took this week out, will return to it next week
21:24fdobridge: <gfxstrand> Okay
21:24fdobridge: <gfxstrand> I kinda figured
22:08fdobridge: <!DodoNVK (she) 🇱🇹> Right now the outside looks like GTA 3 with NAK 🌫️
22:25fdobridge: <mhenning> It can pop multiple off the stack. So, you can run cont from within an if and it will pop off the stack until it gets to the PRECONT entry
22:25fdobridge: <mhenning> Your precedence sounds right, but I haven't checked that too carefully
22:26fdobridge: <karolherbst🐧🦀> @gfxstrand ohh one thing.. the branch targets have no impact on the hw level afaik (same as on turing+)
22:26fdobridge: <karolherbst🐧🦀> you should be able to put whatever, but it helps in debuggers/disassemblers
22:28fdobridge: <karolherbst🐧🦀> also yes.. they have a second input pre
22:28fdobridge: <karolherbst🐧🦀> *pred
22:28fdobridge: <gfxstrand> Well, I got to `Pass: 1423582, Fail: 4, Skip: 1925414, Duration: 1:13:04, Remaining: 8:50` before my kernel died. Do I call it a success? 😩
22:29fdobridge: <karolherbst🐧🦀> and they just act as another execution predicate `and`ed with the normal one
22:30fdobridge: <karolherbst🐧🦀> at least.. that's the way on turing, and I doubt it's different on older gens
22:31fdobridge: <mhenning> Some of the old envytools docs are relevant, although they're for G80 so ignore any encoding notes https://envytools.readthedocs.io/en/latest/hw/graph/tesla/cuda/control.html
22:42fdobridge: <gfxstrand> That seems to contradict what @mhenning said about being able to use them in the place of jumps
22:45fdobridge: <karolherbst🐧🦀> mhhh
22:45fdobridge: <karolherbst🐧🦀> I think it depends on the architecture...
22:46fdobridge: <karolherbst🐧🦀> though... mhh
22:46fdobridge: <karolherbst🐧🦀> yeah I think for break/cont they should matter, but not necessarily for ssy
22:47fdobridge: <karolherbst🐧🦀> ssy is super weird on some architectures
22:47fdobridge: <karolherbst🐧🦀> I think on kepler it's a flag on each instruction and the sync happens on the enxt one
22:48fdobridge: <mhenning> My understanding is the hardware branches to the address from the PRECONT/PREBREAK/SSY (that is, the stack entry) not the address from the CONT/BREAK/SYNC
22:49fdobridge: <karolherbst🐧🦀> yeah...
22:49fdobridge: <karolherbst🐧🦀> the pre one should be the defining one
22:50fdobridge: <karolherbst🐧🦀> but not sure they had encoding space for the target?
22:50fdobridge: <karolherbst🐧🦀> at least on turing the address is totally ignored
22:51fdobridge: <karolherbst🐧🦀> and I was under the impression that's also true on at least some previous gens as well...
22:52fdobridge: <karolherbst🐧🦀> but I might be wrong there
22:52fdobridge: <gfxstrand> The pre ones all have encoding for the target
22:52fdobridge: <gfxstrand> The pop ones don't
22:53fdobridge: <mhenning> There might be encoding space for an address on con/break/sync on some archs but the hardware doesn't care and codegen doesn't set it
22:53fdobridge: <gfxstrand> Which makes sense because a sync instruction basically says "pause this thread and go find something else to run until everyone in the sync is at the sync target.
22:54fdobridge: <mhenning> Yeah, the encoding space is there just for debuggers on archs where it exists
23:01fdobridge: <karolherbst🐧🦀> the problem is, the meaning of what sync means changed quite a few time
23:01fdobridge: <karolherbst🐧🦀> it was all a bit different on tesla, fermi-kepler1? or 2, and then maxwell+ or something
23:01fdobridge: <karolherbst🐧🦀> and weird in like... subtle ways
23:02fdobridge: <karolherbst🐧🦀> like on one arch you marked an instruction as sync and before that one can be executed, all threads need to arrive
23:02fdobridge: <karolherbst🐧🦀> but I'd have to dig around to figure out which gen behaved how
23:49fdobridge: <gfxstrand> Yes, that's definitely a thing for subgroup ops
23:49fdobridge: <gfxstrand> PTX is a mess because ofit
23:49fdobridge: <gfxstrand> PTX is a mess because of it (edited)
23:51fdobridge: <mhenning> From envytools docs, it looks like G80 behaves like this for sync. kepler2 (which is where I did the RE work) does not work this way for sync - it jumps to the stack address
23:52fdobridge: <gfxstrand> I'm not too interested in Fermi at the moment
23:59fdobridge: <mhenning> Yeah. I don't know which behavior Kepler1 has, although that's maybe not the highest priority either