00:00imirkin: although i can't speak to the real design decisions
00:00alyssa: might be worth us piping that through mesa/st at some point
00:00alyssa: (us being bbrezillon or I)
00:00imirkin: nvidia also has a "flip things around" bit that i never cared to expose
00:00alyssa: though tbh I don't care enough
00:00imirkin: the extra subtract in the shader is just not worth it imo
00:00imirkin: (it = the pain of piping it through)
00:00alyssa: I'd be more worried about the extra draw-time compile
00:01imirkin: nobody draws directly to the winsys fbo
00:01imirkin: at least not with complex shaders
00:01imirkin: if they do, they deserve everything that's coming to them
00:02alyssa: tiler here, please use the winsys...
00:02imirkin: have you looked at the reorder thing that freedreno does?
00:02imirkin: pretty clever stuff imo
00:03imirkin: (kudos to robclark for creating it)
00:04imirkin: render to winsys implies limited formats, etc. there's a reason people want all those new formats that ES3 added.
00:04imirkin: i know you want things to be faster for tiling, but ... you'll be holding back the ocean with a broom
00:11robclark: the overlap between gl_PointCoord and caring about an extra few instructions or a shader recompile on the first frame has *got* to be low
00:11robclark: I mean, neverball isn't really pushing the limits
00:11marex: it pushes limits of my knowledge at least
00:12marex: uh ... is it possible nir_lower_texcoord_replace_impl() replaces gl_in_TexCoord0 with gl_Color ?
00:12marex: I mean, that's one of the differences I see in the NIR output diff
00:14alyssa: robclark: everball is stuck at 20fps right now for me
00:14robclark: maybe use NIR_PRINT=1 to dump out nir after each pass (which iirc in most cases should only print if pass makes progress)? And then grep that to find where it appears
00:14alyssa: then again this is on bifrost where not much opt work has happened, oh and i'm playing on a 4k monitor :p
00:14imirkin: robclark: yeah, that's why we never piped that through :)
00:15robclark: heheh, neverball on 4k.. that's cute
00:16robclark:has been looking at smoothing out asphalt9 which seems to have a habit of generating new shaders mid-game..
00:17robclark: I added some logging and by part way thru first level it was up to maybe ~1500 shader programs
00:17alyssa: robclark: when life gives 4k, "test" your driver
00:19anholt: robclark: is it actually linking at runtime?
00:20anholt: (and, is it glCompileShader()ing at runtime, or just linking?)
00:20robclark: alyssa: until I more recently upgraded to newer radeon, the one 4k monitor I have was driven by an old low end nv card (which nouveau supported reasonably, but could only drive at 30Hz)
00:21robclark: anholt: afaict it is compiling and linking at runtime :-(
00:21robclark: ie. I see new integer names being created for both shader and program
00:22robclark: the async compile doesn't completely help, since I think they are used too soon after they are created.. but I think threaded ctx + async compile will be the ticket
00:23robclark: (note: the 2nd time you play, shader-cache kicks in and helps a *lot*.. but first impressions aren't as great as they could be)
00:24robclark: ofc, making chrome gpu sandbox happy about all these extra threads created early turns out to be the harder part)
00:34marex: kusma: https://paste.debian.net/hidden/6e913ddf/ is it expected that after the nir_lower_texcoord_replace , the pointcoord is loaded as gl_Color ? Or is there some confusion with the previous VARYING_SLOT_COL0.xyzw which is also gl_Color ?
00:34marex: see line 67 ^
00:38alyssa: ok, i'll delete my point sprite code if you delete yours !8890
00:39imirkin: and mesa gets the enum restrictions wrong for POINT_SPRITE_COORD_ORIGIN. heh.
00:40imirkin: it lumps it with ARB_point_sprite, foolishly
00:40imirkin: why would anyone think those go together ... sigh
00:42imirkin: hrmph, core mesa code seems to think it came in via GL 2.0
00:43imirkin: which the GL 2.0 spec seems to support. so why do we have a specs/gl-3.2/pointsprite-origin.c piglit test
00:44imirkin: yeah ok. looks like it's been there since GL 2.0
00:44imirkin: just need to move the test.
00:44imirkin: that makes more sense.
00:45anholt: well, and make it not needlessly 3.2-specific
00:45imirkin: other than the bits at the very top, i don't think it is
00:46anholt: I saw 150 shaders
00:46imirkin: in the point coord one
00:46imirkin: which i'm double-checking when it was added
00:47imirkin: looks like GLSL 1.20 got gl_PointCoord
00:48imirkin: that -coord.c one seems like it's testing for a very specific driver bug
00:48imirkin: i guess "wrong thing gets replaced"
00:49imirkin: but since i can't test on buggy drivers, i'm going to leave that one alone - who knows what caused the issue
00:52imirkin: alyssa: just re-read the spec. looks like i lied.
00:52imirkin: alyssa: gl_PointCoord's "origin" is also controlled by POINT_SPRITE_COORD_ORIGIN, same as the replaced values.
00:53imirkin: looking at GL 3.2 spec seciton 3.4.1 "Basic Point Rasterization"
00:54imirkin: however this can still be set to a value independent of the winsys-vs-fbo orientation
00:57alyssa: imirkin: groan :p
01:02reduz: Hi folks! I have possibly a RADV bug doing something quite complex in Vulkan, that It would take me too long to isolate to make a test case. (same thing works fine in all other GPU brands or AMD proprietary). Can I submit a renderdoc capture somewhere? where do I submit?
01:04reduz: I guess not many tried to do this, so I suppose it makes sense it may be broken on RADV :P
01:04Plagman: yeah a bug report on gitlab would be great
01:04Plagman: do you have a spot to store the trace?
01:04Plagman: (what is it doing?)
01:05kisak: ( https://gitlab.freedesktop.org/mesa/mesa/-/issues )
01:11reduz: Plagman: you mean the renderdoc capture?
01:11reduz: should I upload it somewhere and link?
01:12bnieuwenhuizen: that would be ideal
01:12reduz: alright, thanks
01:29alyssa: https://rosenzweig.io/sched.txt These results are saisfying :p
01:31emersion: eh, nice!
01:37alyssa:wonders why her ethernet is broken half the time if she has an external monitor plugged in...
01:37alyssa: oh rk3399..
01:41reduz: ok here we go
01:49reduz: hope no one has to pull their own hair with this one, it's a quite uncommon combination of stuff, heh
01:50bnieuwenhuizen: reduz: "Does the issue reproduce with the LLVM backend (RADV_DEBUG=llvm) or on the AMDGPU-PRO drivers?
01:50bnieuwenhuizen: No, issue is only RADV" what about RADV_DEBUG=llvm?
01:51reduz: bnieuwenhuizen: RADV_DEBUG=llvm yes, AMDGPU-PRO no
01:51reduz: also when doing RADV_PERFTEST=aco , the bug does not appear
01:52bnieuwenhuizen: reduz: did you try anything newer than mesa 20.0?
01:52bnieuwenhuizen: if RADV_PERFTEST=aco helped you might be interested to nkow that is the default since mesa 20.2 :)
01:53reduz: oh I just realized I have 20.0.8 , I for some reason though the version number was 20.8, since I got a ppa that supposedly got me the latest version
01:54reduz: bnieuwenhuizen: May not that be masking the issue though?
01:54bnieuwenhuizen: reduz: it is an entirely new compiler that we switched in
01:55reduz: oooh I see, so I guess this was actually a bug in the older compiler
01:55bnieuwenhuizen: issue may still exist with the old compiler, but not sure what effort we want to spend these days to fix that
01:55bnieuwenhuizen: especially since a lot of the benefits of the new compiler are better defined behavior around subgroups
01:56kisak: it's also possible that a bug in llvm 10.0.0 has been fixed in a newer llvm
01:57bnieuwenhuizen: very true
01:57reduz: oh I see, so I guess I should just tell users with this problem to use the ACO backend.
01:58reduz: Thanks lots!
01:58kisak: or update mesa in general
01:58kisak: RADV/ACO is the default in current releases
01:58bnieuwenhuizen: yeah the update is more recommended, we've fixed more stuff in the past year :P
02:00reduz: problem is the users running distros like Ubuntu LTS, they generally dont want to touch anything
02:00reduz: is it bad if I force environment for Mesa to use ACO?
02:00reduz: before loading the icd?
02:00reduz: (from the C++ Code)
02:00bnieuwenhuizen: not really
02:01imirkin: reduz: if you don't want to touch anything, then you'll just keep on having whatever issues
02:01imirkin: in order to resolve issues, gotta touch something...
02:01bnieuwenhuizen: but note that 20.0/20.1/20.2 are EOL so even if we fix issues those older releases won't get the fixes
02:01imirkin: LTS = "if it worked before, it'll keep working, plus security fixes". doesn't seem like the first condition is satisfied, so ... yeah.
02:02bnieuwenhuizen: though for this issue seems like a workaround. (note that on newer versions the environment variable will throw a warning)
02:02reduz: no problem with that, the issue is that users make games in Godot and export them to different platofrms for other to play and kinda dont like having to ask their players to upgrade, specially when so many run Ubuntu LTS
02:03reduz: so I dont have much of a choice to add this workaround for the time being
02:03bnieuwenhuizen: I thought with new Ubuntu releases the LTS version would get the newer releases through a HWE update, but sounds like this has not happened here
02:03reduz: I would expect that to happen too, but did not seem like the case
02:03bnieuwenhuizen: kisak: ^ you remember how HWE updates work?
02:04kisak: yeah, about 3 months after a short-lived Ubuntu release, the kernel, X, and mesa are backported to the newest LTS
02:05kisak: For 20.04, mesa 20.2.6 is in focal-updates
02:08imirkin: reduz: yeah, that's the problem with the LTS model
02:08imirkin: unfortunately we can't really control that
02:09imirkin: feel free to complain to ubuntu!
02:10kisak: Ubuntu 20.04 released with mesa 20.0.4, 20.0.8 shouldn't be available for it anymore
02:11bnieuwenhuizen: yeah, looking through history 20.2.1 has been available since nov for ubuntu 20.04.1 sounds somebody should get through their regular ubuntu updates
02:30marex: imirkin: kusma: hey uh ... count it be that nir_lower_texcoord_replace_impl() is missing pntc->data.driver_location assignment after pntc = nir_variable_create() , and that is why the NIR dumps incorrectly list /* gl_Color */ instead of /* gl_PointCoord */ ?
02:30imirkin: i don't know anything about nir :)
02:30imirkin: good luck though
02:33marex: imirkin: thank you
02:38alyssa: marex: uhh
02:38marex: alyssa: I still barely have any clue what I'm doing here btw
02:39alyssa: I don't believe the NIR pass should be setting driver_location, that's for lower_io to do..
02:43 #intel-3d: dcbaker: Alexey-UA-2020: you might have better luck with that on #freenode_#dri-devel:matrix.org , this channel is really about i965, iris, and anv
02:43marex: hmmmmmm, etnaviv is calling that right after I call nir_lower_texcoord_replace
02:45alyssa: swap the order
02:45alyssa: no, that's right
02:46alyssa: I think
02:46alyssa: marex: Why are you calling lower_texcoord_replace in the first place?
02:46alyssa: that's for mesa/st to worry about
02:46alyssa: don't set PIPE_CAP_POINT_SPRITES and mesa/st will call it for you if needed, see !8890
02:47alyssa: at least in theory, apparently that's slightly broken
02:47marex: heh :)
02:48marex: I tried removing the PIPE_CAP_POINT_SPRITES already, and ran into other strange behavior
02:48Alexey-UA-2020: could someone answer some questions about compiling / linking mesa3D ?
02:48marex: so I figured I'll just try adding the pass and see what it does
02:51marex: alyssa: ah, right, after that nir_lower_io, I get this https://paste.debian.net/hidden/6e913ddf/ line 67 gl_Color
02:51marex: I believe that should be gl_PointCoord
02:52marex: but maybe I'm not using the nir_lower_io correctly, lets see
03:12kisak: reduz: what mesa PPA were you referring to earlier?
03:16reduz: This one
03:18kisak: okay, something's definitely wonky with apt for you to look into, there's no way that's actually being used. (oibaf shows up as random git commits, not point releases)
07:44pq: xyene, did you actually have a separate GL context current in each thread and created so that they really share textures? If yes, sounds like there is some Mesa problem with keeping proper references, unless this is declared unsupported usage.
07:47pq: I'm not quite aware of what the GL rules of respecifying textures from threads is.
07:49pq: xyene, anyway, running those two threads unsynchronized seems like a bad idea to begin with. You might want to have two texture, and update the one that the rendering thread is currently *not* using.
07:49pq: then swap textures
07:49pq: otherwise you don't know which frame you are using
09:54MrCooper: reduz: setting that environment variable in a library is kind of nasty (and could at least theoretically break things with older Mesa); at the very least, please make sure not to clobber it if it's already set
10:09MrCooper: dcbaker: ugh, looks like meson doesn't print stdout/stderr from timed out tests at all :(
14:17alyssa: Kayden: This is a theoretical pathology, but should info->uses[offset]++ in brw_nir_analyze_ubo_ranges saturate? In case it's used 256 times or something.
17:01marex: kusma: does this change https://gitlab.freedesktop.org/marex/mesa/-/commit/7b34442954e6a94a202041337b2306f1c9066e76 make sense ?
17:01marex: that's because in etnaviv, https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/src/gallium/drivers/etnaviv/etnaviv_compiler_nir.c#L1070 here , when the NIR passes are applied, the driver_location is apparently already assigned to the variables
17:02marex: so uh ... if I use the nir_lower_texcoord_replace_impl , the new gl_PointCoord variable will end up having driver_location = 0 and alias with whatever variable had driver_location = 0 in the nir program before
17:02marex: alyssa: jekstrand: ^
17:04kusma: marex: Yeah, kinda. I think we ignore the driver-location in Zink, because gl_PointCoord maps to a built-in in SPIR-V.
17:05kusma: marex: So, I don't think doing this is a problem for us at all.
17:08xyene: pq: yes, to the best of my knowledge. I put together a short self-contained example demonstrating the crash at https://gitlab.freedesktop.org/mesa/mesa/-/issues/4240
17:08xyene: might still be listed as explicitly unsupported somewhere I haven't looked :)
17:08marex: kusma: all right, thanks for checking
17:09xyene: agreed on points re: having the threads be unsynchronized, in practice this situation only cropped up once something else had gone wrong, so that advice is sound :)
17:12marex: kusma: unrelated question, if I remove PIPE_CAP_POINT_SPRITE from the driver pipe caps, that only automatically lowers the pointcoord for NIR, but not for TGSI, right ?
17:18kusma: marex: It only works for drivers that prefers NIR, if that's what your'e asking. It won't touch TGSI, but you shouldn't really get TGSI for "normal" shaders if your driver prefers NIR these days.
17:19kusma: TBH, I'm a bit unsure if most drivers will ever get TGSI these days... anholt?
17:19robclark: virgl and vmwgfx are still on the TGSI train
17:19imirkin: not to mention nouveau
17:22marex: kusma: etnaviv has both, but NIR should be default ... soon
17:50macc24: can anyone help me with developing a panel driver?
17:50macc24: i am trying to make elida kd50t048a work on mainline linux
17:50macc24: so far it's fine but i have a stupid bug
17:51macc24: colors are constantly wrong and changing color format doesn't make them work except RGB565_PACKED, but then i have to launch sway, shut down sway, and then re-launch sway back again to have correct colors
17:53imirkin: link to code might help
17:53imirkin: sounds like you're doing something wrong :)
17:53macc24: yes i am doing something wrong
17:54imirkin: could be how you're hooking up the panel in the dts, could be in how you're configuring the formats, etc
17:54macc24: ill link whole panel driver in a minute
18:00macc24: oh i can't reproduce it now .__.
18:00imirkin: yay, problem solved
18:00macc24: it's now weird constantly
18:01macc24: and i think i am the first to play supertuxkart on that hardware xD
18:01imirkin: esp with weird colors
18:01macc24: f u n k y
18:03macc24: dts binding: https://github.com/Maccraft123/linux/blob/odroidgo/arch/arm64/boot/dts/rockchip/rk3326-odroid-go3.dts#L274-L287
18:03pcercuei: What is RGB565_PACKED? Isn't "regular" RGB565 packed already?
18:03macc24: and panel itself: https://github.com/Maccraft123/linux/blob/odroidgo/drivers/gpu/drm/panel/panel-sitronix-st7701.c
18:03macc24: pcercuei: some format, it doesn't matter now anyway since it now just never displays the correct colors :/
18:04macc24: the whole init sequence was borrowed from downstream dts binding
18:04imirkin: macc24: what docs do you have on the panel?
18:04macc24: imirkin: none
18:04imirkin: e.g. a downstream driver?
18:04pcercuei: your code says RGB666 packed, that makes more sense
18:05macc24: imirkin: https://github.com/hardkernel/linux/blob/odroidgoA-4.4.y/arch/arm64/boot/dts/rockchip/rk3326-odroidgo3-linux.dts#L367-L589
18:05imirkin: slightly more sense. are you sure it's not just RGB888 like the other panel?
18:05macc24: it's now
18:06imirkin: in the thing you pasted: dsi,format = <MIPI_DSI_FMT_RGB888>;
18:06imirkin: maybe you're missing something in the init sequence to force that mode
18:07macc24: hmm, ill doublt check
18:07imirkin: but confusing RGB666_PACKED and RGB888 would definitely cause some color issues ;)
18:09macc24: colors on RGB888 are somewhat fine, just look like on 2007 tn panel
18:09macc24: and kmscube looks bad
18:11imirkin: define 'bad'
18:11imirkin: you should very carefully look over that init sequence
18:11imirkin: hmmmmm ok
18:11imirkin: colors are still odd then.
18:12imirkin: but it could be worse!
18:13macc24: on color selection menus there is weirdness too
18:13macc24: imirkin: like this https://i.imgur.com/CEFpNOp.jpeg
18:13macc24: they move when i change the hue
18:14imirkin: among other things, you set a sleep delay of 80, while the comments in the thing say 250ms
18:15imirkin: and you're off-by-1 on the 0xE2 setting
18:15imirkin: i.e. missing a 0
18:16macc24: oh i didn't notice that
18:17imirkin: and your init sequence appears to be missing some bits at the end
18:18imirkin: also i'm not 100% sure what the 0x15 vs 0x39 stuff is at the start
18:18imirkin: but i don't see how that's reflected here.
18:18macc24: it doesn't really matter
18:18imirkin: but i also don't know anything about the MIPI protocol
18:21HdkR: dcbaker: 21.0.0-rc4 is tagged without an email to the ML?
18:22macc24: imirkin: it now works perfectly fine
18:23macc24: "perfectly fine" as in "looks ok, but i don't know if i'm hallucinating it from starting at one cube for few hours)
18:24macc24: thanks for help
18:24imirkin: macc24: it was the extra 0?
18:24macc24: i don't know, i written the rest of init sequence that i missed
18:24imirkin: ah ok
18:25imirkin: i guess those init sequences aren't just random bytes afterall ;)
18:26macc24: do you have better idea on implementing different init sequences than a switch(st7701->desc->panel) with magic values?
18:26imirkin: you could specify the different function in the descriptor
18:26macc24: the what?
18:27imirkin: the struct you use
18:27imirkin: to describe the panel
18:27macc24: i can point at functions there?
18:28imirkin: i mean ... it's just variables
18:28imirkin: functions are first-class objects in C
18:28imirkin: so yes
18:29macc24: and now i have no excuse to fix sound on it
18:36marex: jekstrand: Hi, is there some pass which would remove FS inputs that are not used in the FS ?
18:36marex: decl_var shader_in INTERP_MODE_NONE vec4 gl_in_TexCoord0 (VARYING_SLOT_TEX0.xyzw, 1, 0)
18:36marex: ^ like this one, there is nothing in the FS that is using it
18:37marex: nir_remove_unused_varyings() in link stage does not seem to do the trick
18:38LordKitsuna: Could someone help guide me on making a good bug report? or point me to a better irc channel to use? i am having gpu total lockup when playing Dyson shpere program (its a vfio and the gpu falls off the host bus entirely) but so far its literally only when playing that game others i can play all day no problem. sometimes i can play for hours sometimes it doesnt even make it 2 min. i cant figure out how to give solid debug information since
18:38LordKitsuna: the crash takes out the vm entirely so when i try to record logs in the background they are not getting written to disk. i tried using mesa-git but that actually made the crashes worse it dies before it even makes it in game 100% of the time on the current git
18:38macc24: LordKitsuna: can you try on mesa-git?
18:38imirkin: LordKitsuna: maybe mention what hw you're using?
18:39LordKitsuna: ah right sorry, its a 6800XT MSI gaming trio X
18:39imirkin: so ideally, you'd have repro steps
18:39imirkin: but in this case, that might not be possible
18:40LordKitsuna: well with mesa-git at least currently the repo steps are "open the game and attempt to load in" but on arch's current mainline mesa its just at random
18:41imirkin: i assume this is a vk game, not gl?
18:41LordKitsuna: I am using DXVK to play it so yes but no i guess?
18:42imirkin: well, as far as mesa is concerned, vk
18:42dcbaker: HdkR: I must have forgot to send the email, the last few days have been pretty hectic. I'll get the email out today
18:42imirkin: ideally you can convince one of the radv developers to try it out themselves
18:43imirkin: coudl be that the insta-crash is unrelated to the sometimes-crash
18:43LordKitsuna: its only $20 so i would be more than happy to donate a copy if one of the mesa devs if they give me a steam name lol
18:43imirkin: valve sponsors some of the radv development, so that may not be necessary
18:46hch12907: LordKitsuna: even journalctl -xe doesn't show the relevant logs?
18:46LordKitsuna: i can take a look one sec but it seems like the crash is pretty instant and nothing makes it to disk
18:48LordKitsuna: yeah i dont see anything in there sadly
18:49hch12907: that's a nasty crash
18:49LordKitsuna: the music keeps playing without skipping around after the crash so the system clearly doesnt entirely die, maybe i can use ssh to collect the logs network might not die entirely
18:50hch12907: if everything else works other than the screen then I think it can be a gpu hang
18:50hch12907: but I am not a radv dev
18:51LordKitsuna: well clearly something in the background is going dead since the logs stop writing to disk but yeah it seems some other things stay alive
18:52LordKitsuna: ive got ssh all loaded up and watching dmesg on my laptop so ill start playing again and we will see if it crashes again, if it does hopefully i get something
18:52imirkin: pro tip: dmesg -w
18:54LordKitsuna: yeah thats what ive got up, also tailing the xorg log just in case that spits something
18:54hch12907: oh yeah, you can try running the game with RADV_DEBUG=llvm and see if that crashes the system
18:55LordKitsuna: welp it crashed, but this time it crashed so hard it took out the host system as well not just the vm, all sound everything dead instantly
18:56LordKitsuna: that happens sometimes but is much more rare usually the host isnt affected
18:56LordKitsuna: nothing made it from the ssh sadly
18:56LordKitsuna: ill try llvm and see if it still crashes
19:05LordKitsuna: hmm game opened but i dont see llvm mentioned in the logs, would it indicate that i used that flag if it loaded it properly?
19:08hch12907: I think dxvk logs will list out the device name
19:08hch12907: something akin to AMD RADV SIENNA_CICHILD (LLVM) I guess?
19:10hch12907: but if the game works with LLVM then ACO is at fault here, you can mention that in the bug report
19:29LordKitsuna: seems i was missing some game updates and one of them does mention game crashes, updated and going to play around normally for a bit and see if that gets it. since this is the only game that crashes for me maybe i can get away with blaming the game and not mesa/radv
19:31dschuermann: LordKitsuna: we'd be happy to have a look. do you mind going over at https://gitlab.freedesktop.org/mesa/mesa/-/issues/new?issue%5Bassignee_id%5D=&issue%5Bmilestone_id%5D= and select the (AMD Radeon Vulkan) template? it contains some advice what would help us (you don't have to fill in everything, just whatever you got)
19:32dschuermann: donating the game won't be necessary if it's on steam ;)
19:37LordKitsuna: Yeah i will take a look at it, tho as mentioned it may be resolved it turns out i was behind on some game updates that mentioned crashing and so far after applying them its been behaving so it might just be the game was stupid and mesa just handled it a little worse than windows lol
19:37LordKitsuna: i am going to keep playing and see if i can get it to crash again
19:41dschuermann: these are the kind of bugs I like most :P
19:43dschuermann: generally mesa tends to be less forgivable as (at least from my impression) it's more strictly based on the specs and does only add game-specific workarounds if it's absolutely unavoidable
19:46LordKitsuna: i just wish GPU had a hardware reset button on them, PCIE has supported hotplug since its first version but no one implements it. would make GPU hard crashes so much less of a problem lol
19:47LordKitsuna: especially in a VFIO enviroment where the host _usually_ keeps on going
19:47HdkR: Was it confirmed that RDNA2 fixed the VFIO reset problem? I don't remember
19:48LordKitsuna: yes it resets properly provided its not a hard hang lol
19:48LordKitsuna: but just changing vm os or rebooting it resets fine
19:52LordKitsuna: so far other than this one game that was being stupid the 6800XT has worked fantastic for me so thats been nice. RDNA1 was a little more...bumpy for ahwile there lol
23:49imirkin: can you do dma-buf stuff with depth surfaces?
23:58HdkR: Curious, sway by default thinks the HMDs are something it should treat as a monitor?
23:58HdkR: Or is that a wayland quirk?