00:04 cubanismo[d]: we call that block height, FWIW.
00:04 cubanismo[d]: And no, it is independent of the page table attributes
00:04 cubanismo[d]: It would only matter if it were linear instead of block linear.
00:05 cubanismo[d]: I don't think linear can use the compressed PTE kinds even with Turing+
00:05 cubanismo[d]: But it can use the uncompressed generic one.
00:06 cubanismo[d]: I think Nouveau ignores that and continues using the old 0x0 page kind for linear for no real reason, last I asked bskeggs anyway.
00:10 cubanismo[d]: You're also free to use the same block-height for all planes of a YCbCr image though even if the Cb & Cr planes are decimated. It's just slightly less optimal. That's what we have to do for e.g., format modifiers anyway, because the community decided to rip out per-plane modifiers right before we added modifier support and mentioned our HW slightly preferred per-plane layouts.
00:20 airlied[d]: I think some of the video dec or enc hw has some limitations on differing modifiers for the planes anyways
04:56 tricolorhendry: So after all the simplification is done at precompile time single element can be accessed so: upper operand of subtract is 540+540 and lower one being as 540−219−84−108−72=57 and same treatment for 483 get's to 540-57+540-0=483+540, so 57 as result 540+540 would get to 483+483 on the other hand, and hence zero result. but without treatment as before whatsoever but cancellation routine
04:56 tricolorhendry: as in the end 57 and 114, so hence the cancellation being -270+84=-156+36+6=-114, something like this is the use of the dance, might have to be more thoughtful, yeah anyways i am tired time to sleep.
08:18 mohamexiety[d]: cubanismo[d]: Alright, thanks a lot!
12:12 gfxstrand[d]: airlied[d]: Yes. Planes have to be tiled the same
14:38 karolherbst[d]: mhenning[d]: do you have some time/motivation to look into a weird instruction scheduling issue I'm seeing? Like.. not even sure it's scheduling related, but it feels like it
14:39 karolherbst[d]: or anybody else
14:40 karolherbst[d]: I was looking into wiring up nir opts, and this part of a shader stood out: https://gist.github.com/karolherbst/b5755244cca9fdf50328fd03e06fa70f#file-b-after-L539-L611
14:40 karolherbst[d]: the shader goes from 40 to 88 gprs
14:40 karolherbst[d]: and it feels... unnecessary?
14:41 karolherbst[d]: or rather some reordering happens, but not in a way I'd expected it to happen
16:38 mhenning[d]: karolherbst[d]: well, on main we only reorder after RA, which means that scheduling never changes register counts
16:38 mhenning[d]: it might be better with the pre-RA scheduler branch
16:38 karolherbst[d]: ohhh... right I forgot about that
16:38 karolherbst[d]: yeah, I might try it out with that one
16:49 mohamexiety[d]: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13974 how do I handle this? :thonk: on one hand we don't really do hotplug (let alone hotplug while stuff is running on the GPU) but on the other hand the issue says it used to work so I am a bit confused
16:55 marysaka[d]: imo hotplug is barely supported espcially in nouveau so like...
17:39 gfxstrand[d]: Yeah, kernel-level hotplug might be a thing but we don't support it in NVK, much less the rest of userspace
18:07 gfxstrand[d]: Literally listening to people talk about hotplugging right now...
18:10 mohamexiety[d]: :nervous:
18:11 mohamexiety[d]: tbh I dont think even Windows could handle the scenario in that issue as they're doing hotplugging while stuff is running
18:11 karolherbst[d]: well
18:11 karolherbst[d]: you _can_ _somehwat_ _support_ it if you have all the right pieces in place
18:12 mohamexiety[d]: yeah just not when stuff is on the GPU
18:12 karolherbst[d]: there is a lot of work the kernel needs to do in order to do it properly
18:12 karolherbst[d]: uhm.. no, still
18:12 gfxstrand[d]: And your compositor needs to be able to deal with it
18:12 karolherbst[d]: you don't have to freeze just because the GPU is gone
18:13 karolherbst[d]: like the current issue we have is that a lot of UAPI just hangs forever 🙃
18:13 mohamexiety[d]: if it's the primary GPU how do you handle that though?
18:13 gfxstrand[d]: yes
18:13 mhenning[d]: I wonder if the "regression" there is just using modifiers
18:13 karolherbst[d]: mohamexiety[d]: nuke the accel context, create a new one
18:13 mohamexiety[d]: hm
18:13 karolherbst[d]: create a robustness context for starter 😄
18:13 mhenning[d]: like maybe forcing the sw path will get back to the previous behavior
18:13 karolherbst[d]: and treat it as a context loss
18:13 karolherbst[d]: and make the application deal with it
18:14 karolherbst[d]: but the thing is, that most compositors aren't built for it
18:14 karolherbst[d]: I had this discussion with some mutter devs and some just said: we'll probably have to start from scratch to do it properly
18:15 karolherbst[d]: like apple does it properly for over 15 years now
18:15 karolherbst[d]: 🙃
18:16 karolherbst[d]: or did until they ditched intel
18:21 magic_rb[d]: Isnt it like what android does? "Oh btw your context? Yeah its gone, start over"
18:23 gfxstrand[d]: Android has the GPU and CPU in the same SoC
18:23 karolherbst[d]: are there android phones with thunderbolt support..
18:25 steel01[d]: Android is more than phones. For one, android-x86 is a thing. Booting on a normal laptop/desktop. Then you've got tablets with hdmi, for example the shield tablet. Hotplug on android is something I deal with a lot.
18:27 steel01[d]: Not sure about thunderbolt specifically. But there's phones with usb c alt mode support too.
18:27 gfxstrand[d]: display hotplug, yes. Hotplugging whole GPUs, no.
18:27 magic_rb[d]: No i meant, specifically the "your context is gone, have fun" i know they do that to preserve power
18:27 steel01[d]: Oh, is the conversation gpu hotplug? Ah, I misread.
18:27 gfxstrand[d]: But yes, Android destroys and re-creates apps at will
18:28 gfxstrand[d]: So you could totally do that when the GPU blinks out
18:28 steel01[d]: Android semi does gpu hotplug. Going to sc7/lp0/whatever different vendors call that. The gpu gets turned off.
18:29 karolherbst[d]: the benefit on android is, that VRAM isn't gone when that happens
18:29 karolherbst[d]: though could also just fault on the pages anyway
18:37 HdkR: Even the most simple thing is that when the app gets backgrounded, your WSI framebuffers are guaranteed to be deleted. So an app developer always needs to deal with /something/
18:41 HdkR: We've got Linux applications that get upset if WSI returns suboptimal, I can only imagine how they would explode on Android :P
18:46 gfxstrand[d]: The difference is that Linux applications generally assume the OS won't kill them just for fun. Android is very violent.
18:47 karolherbst[d]: maybe we should start doing that lol
18:47 mohamexiety[d]: so what I am reading here is the solution is to make oom killer more violent
18:47 karolherbst[d]: apps in the background doing pointless things is a thing sadly
18:47 steel01[d]: Oi, oom is already violent enough. I had to switch off systemd-oomd because it'd murder kde and all the graphical stuff in the middle of an aosp compile.
18:48 HdkR: Any application with a DRM context open, immetiately has higher priority to OOM.
18:48 HdkR: immediately
19:31 kicchou: what's up irc gang; i'm the newbie that submitted "[1/2] drm/nouveau: add missing DCB connector types" one month ago yesterday and i'm reaching out to ask what the timeframe is on reviews. ik you all are managing much more important stuff rn. what should i be doing to aid my contribution's visibility and get a review? again, i'm new here so please be patient
19:31 kicchou: with me
19:45 karolherbst: kicchou: it looks like only the first patch made it to the ML?
19:51 kicchou: from what i'm seeing on the patchwork site [https://patchwork.freedesktop.org/series/154064/#rev2], both parts 1 and 2 made it through but the cover letter got nuked
19:54 kicchou: the cover letter has subject [[PATCH 0/2] drm/nouveau: add and implement missing DCB connector values]
20:35 cubanismo[d]: gfxstrand[d]: Android apps get a chance to shut down cleanly when t though, right? That's a major improvement in the app experience compared to "Ur dead" from OOM killer on vanilla Linux.
20:35 cubanismo[d]: *when their app garbage collector thing is triggered
20:36 marysaka[d]: mhenning[d]: planning to poke at the comments you left on !37475 (and review the new bits added) tomorrow btw
20:37 HdkR: I think cgroups can configure if your application gets notified of memory limits through signals, but no one does that since you can't anticipate applications responding to a signal correctly.
20:37 dwfreed: especially fun when a signal's default disposition is "core"
20:38 HdkR: That's a good one
20:38 HdkR: Oops, SIGPIPE/SIGIO, time to explode.
20:39 dwfreed: at least those are term, but SIGIO shouldn't be
20:39 dwfreed: SIGQUIT is core, and that's the really dumb one
20:40 dwfreed: as is SIGXCPU (you ran out of CPU) and SIGXFSZ (you ran out of file size)
20:40 HdkR: SIGXCPU is a fun one for sure
20:40 HdkR: Mono uses that one for its garbage collector I think
20:41 dwfreed: cute
20:42 HdkR: Don't tell Linux but I don't queue non-RT stignals correctly in my emulation.
20:44 HdkR: As in I do queue them instead of losing the data as it should...
21:01 karolherbst: kicchou: mhh weird.. I only recieved the cover letter and patch 1. But anyway, I think it would be best to only add the connector type you were running into were missing, because the others could have subtle differences that need special handling
21:03 kicchou: karolherbst: thanks for the feedback; should I keep the WARN_ON macro change, though? if i'm not going to add the other connectors, i don't think they should issue full on warnings
21:03 karolherbst: why not?
21:04 karolherbst: mhh well.. I guess a proper warning is in order
21:04 kicchou: because the printk is clearer as to what went wrong and a port being labeled incorrectly in firmware isn't DEFCON 1 imho
21:05 kicchou: besides, that was the behavior before linux 6.5
21:05 kicchou: just a printk for unexpected DCB connector values
21:15 karolherbst: ahh I see
21:16 karolherbst: yeah a proper print is fine, I somehow understood is as removing it, sorry for the confusion
21:20 kicchou: all good, thanks for the feedback! i'll resubmit a v3 with those changes this weekend.