07:11 sravn: mripard ^
09:25 j4ni: PSA: all 'dim' users must update now. Details at http://lore.kernel.org/r/87sg8qkgge.fsf@intel.com
11:51 meido123: So the memory allocation in linux , when programs like libreoffice start to use more memory than 4GB, objects/data will be allocted to swap filesystem, so context switch on some CPUs no longer meets the timing schedule, which means interrupt request queue in hw will fill in. Keystrokes or mouse gestures are no longer registered, since software shared eventloops in shared memory will be also swap allocated so none of the reads or write into sw
11:51 meido123: eventloopqueues really do not even take place, cause the hw queue retries them without evicting until they are handled, so hw queue just fills up quickly. Xorg here, not sure how wayland would deliver input events from kernel, there they can be practically also done as part of the context switch, however per proccess other new swapped allocs might still freeze the computer. Since eventhandler might time out if new memory allocations are being done,
11:51 meido123: though it could wake up some random other programs too in such case. For such cases something better than current sw/hw MMU based 4-5level and pagetable allocations can be offered you know. though mmap and sbrk is pretty bad as is swap fs even in case of no pagetables.
18:00 mripard: sravn: what's the context?
18:05 sravn: mripard: linusw had a patch that fixed something and since we are in -rc6 timeframe drm-misc-next will go in feature freeze any day now
18:05 sravn: So fixes no longes goes to drm-misc-fixes but to drm-misc-next-fixes
18:06 sravn: You were the only one of the drm-misc maintainers that was online so wanted to grab your attention on the question
18:48 linusw: sravn, mripard: it's cool, I concluded yesterday that we were not in feature freeze yet so I just merged the patch!
19:06 sravn: linusw: Yeah, and I wasted my sunday on warning fixes in fbdev. One of those "I can do that in an hour or two", and then it ends up taking much longer
19:07 sravn: But it is also nice to see video/ build with no warnings with W=1
19:07 sravn: I have not dared to try W=2 neither in drm/ nor in video/
19:08 linusw: sravn: oops I hope I haven't caused too many of those
19:08 sravn: linusw: None as far as I can tell.
19:09 sravn: I just tried W=2 anyway - it is not pretty. Or at least not on alpha. Will try a more mainstream architecture
19:10 sravn: Nope, arm is not pretty with W=2. I do not wanna go into that rat-hole
19:49 JEEB: is this channel strictly for DRI related stuff, or is general discussion regarding mesa driver behavior on-topic? (such as "how I can best find out where I'm sending out an uninitialized or so surface if 'radeonsi_zerovram' gives me a proper result?")
19:51 airlied: JEEB: yes here is fine
19:51 JEEB: ok
19:52 JEEB: basically I'm trying to figure out any best practices regarding figuring out what is going wrong with https://gitlab.freedesktop.org/mesa/mesa/-/issues/2085
19:53 JEEB: as far as I understand the driver is just taking liberties regarding not zeroing memory etc due to the EGL spec's wording, and somewhere uninitialized memory is getting pushed on screen
19:54 JEEB: mpv could just be added on the compatibility list for radeonsi_zerovram getting enabled, but it'd be nicer to attempt and figure out things
19:57 JEEB: it doesn't seem to happen with wayland, although that could just be the compositor being nice or something
19:59 amonakov: afaict for x11 this cannot be fully fixed on mpv side because it has no way to "delay" window size change until it has zeroed out the resized buffer
19:59 amonakov: as soon as the window manager resizes the window, Xorg will have to display *something*
19:59 JEEB: ok, so in that case just adding it to the compat list would be the way to go?
20:00 amonakov: (but take my words with a grain of salt and wait if someone more experienced responds)
20:00 JEEB: since enabling that radeonsi flag seems to work
20:01 amonakov: the general topic of missing buffer clears was raised a couple of times last week
20:03 amonakov: see https://dri.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&highlight_names=&date=2020-11-30
20:04 amonakov: the ML thread mentioned there is https://lists.freedesktop.org/archives/dri-devel/2020-November/287144.html
20:04 JEEB: also apparently this is only an issue on egl, glx didn't seem to be affected apparently
20:06 JEEB: ok, thanks for some context
20:06 JEEB: I don't myself see this since I'm mostly on intel, but LaserEyess at least is one of the affected
20:08 LaserEyess: I did not try glx
20:08 LaserEyess: I don't think I have glx support built for mpv right now
20:08 LaserEyess: but I can reproduce the issue in radeonsi and zink
20:08 LaserEyess: intel is fine
20:11 i-garrison: fwiw I had not experienced this issue with r600 card, but I'm presented with multicolor zebra each time I boot to sddm on x11 since I moved to radeonsi card
20:13 JEEB: we actually added workaround to our render function that would just clear the image with a static color all the time, but that indeed wouldn't improve resize etc
20:13 JEEB: and now we had to rever that since it indeed did not fix all the issues as well as also dropped intel+mac performance a lot
20:14 JEEB: which is why I'm trying to feel up the actual way to fix it, which in the worst case is to add mpv on the list for radeonsi_zerovram
20:14 LaserEyess: can I set zerovram via an env variable?
20:15 LaserEyess: or do I need to mess with /etc/drirc
20:15 amonakov: LaserEyess: RADV_DEBUG=zerovram, see https://docs.mesa3d.org/envvars.html
20:15 amonakov: ah, that's probably Vulkan only, sorry
20:17 LaserEyess: I'm still goign to try that considering I get this issue with zink
20:17 JEEB: ~/.drirc with https://github.com/mpv-player/mpv/issues/7105#issuecomment-548129967 seems to have made it get applied
20:18 LaserEyess: RADV_DEBUG=zerovram worked
20:19 LaserEyess: it works for radeonsi too
20:19 JEEB: alrighty
20:20 mattst88: amonakov: did you ever release the code for https://www.x.org/wiki/Events/XDC2014/XDC2014MonakovLibrary/ ?
20:28 amonakov: mattst88: no; i guess it's a disappointment, but some things around that discouraged me
20:36 amonakov: mattst88: could you briefly tell me about your interest in that?
20:37 mattst88: amonakov: I was just curious. I remember watching the talk and then I never got the chance to ask you later where the code was :)
20:37 mattst88: I remember thinking it sounded like a pretty cool idea
20:38 amonakov: mattst88: actually you asked me once in this very channel :) back in 2014
20:38 mattst88: oh, hah :)
20:52 airlied: MrCooper: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/6002324 any ideas? just trying to bump the vk test container
23:02 meido123: so all this syscall taped in-kernel malloc/mmap and sbrk code is tbh. real bogus. ELF containers in the context of operand forwarding capable in-order chips are bad too. Cause global variables live in that container, they are mmap/malloc indirected from there. In other words what happens under the hood, is operand is accessed from the same register, i.e register is forwarded, but memory stage gets different address with different indirect addressing mode
23:02 meido123: in machine code, in other words no memory forwarding can happen, cause such address is not going to be in LSQs, once it is resolved in memory stage in the in-order or OoO pipelines :), but in OoO pipelines exchanging integer and FPU destination to source data, takes one additional cycle anyways, i saw that in OR1000 marracchino core too. They have different forwarding networks for different FU types, within the same fu type, it is 0zycles forwarding, but
23:02 meido123: between different ones always 1clock cycle. X86 can be hacked to use memory µops i,e memory destination sources for ALUs, but RISC like ARM is screwed, but luckily all arms had long time ago xtal MMIO and PLL functionality exposed to programmers. https://scienceprog.com/clocking-arm-with-crystal-oscillator-and-pll/
23:51 airlied: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7954
23:51 airlied: mareko, pepp ^
23:55 mattst88: airlied: ah, so the floating-point exception was a divide by zero or something?
23:56 airlied: mattst88: yup