11:21karolherbst: anybody else with a full functional 3 operand logic LUT instruction? like being able to combine any kind of logical operation into one instruction
11:22karolherbst: wondering how this can be encoded inside nir
14:01pcercuei: Is it OK if I add a drm_mode_config_helper_funcs.early_atomic_commit() callback?
14:01pcercuei: I need to commit part of the state before the VBLANK interrupt
14:03danvet: pcercuei, just write your own
14:03danvet: should be the function that covers like 99% of all cases
14:04pcercuei: danvet: I can't do that, atomic_commit_tail is already called too late
14:04danvet: pcercuei, there is nothing that touches hw state before that function is called
14:04danvet: so pretty sure it's not too late
14:04pcercuei: that's the problem :)
14:05pcercuei: it's called after drm_atomic_wait_for_dependencies()
14:05pcercuei: which syncs with the VBLANK interrupt, right?
14:05danvet: I think you need to explain your hw better
14:06danvet: it syncs with the previous commit
14:06danvet: so that you don't have 2 commits overwriting stuff in parallel
14:06danvet: could be that the previous commit takes too long or something like that ofc
14:07danvet: which you can fix by doing your own atomic_commit_tail and shuffling stuff around
14:08pcercuei: My plane has a shadow register for the "next FB address", which is loaded right before I get a VBLANK interrupt. So by the time I get the interrupt, it's too late to swap buffers
14:08danvet: yeah, that's like how most hw works
14:09danvet: if you somehow only get half the refresh rate, then either your drm_atomic_helper_commit_hw_done() is too late
14:09danvet: or your vblank event handling is broken
14:09danvet: and signals too late
14:09danvet: but shadow fb address register works as-is with helpers, no changes needed
14:10danvet: or maybe you have races somewhere, kerneldoc comments has lots of text explaining what all can go wrong in driver code
14:10pcercuei: What I do see, is tearing
14:11pcercuei: What I think is happening, is that the buffer swap happens after the shadow register is loaded, which means that the hardware still uploads the old buffer
14:11pcercuei: meanwhile the application is painting it
14:11danvet: well is the app correctly waiting for all the events?
14:12danvet: also usually it's the vblank event that's busted
14:12pcercuei: the app does call drmModeAtomicCommit(), passing a different software-painted buffer everytime
14:13danvet: if it's a completely new buffer and cpu rendering, then driver bug
14:13pcercuei: it switches back and forth between two or three buffers actually. But these are completely repainted everytime
14:14pcercuei: So, if I understood correctly, my drm_plane_helper_funcs.atomic_update() can be called while the HW is in the middle of rendering a frame?
14:15danvet: but I'd first try to make sure that your app is correct by testing it on other drm drivers
14:15pcercuei: For some reason I thought all of that was done in a VBLANK period
14:15danvet: since if the app isn't waiting for vblank events, then yeah you get corruption
14:16danvet: not all hw needs that, enforcing that would be classic midlayer mistake
14:16danvet: real soon now (once nouveau lands in drm.git) we will have a nice helper which provides you vblank workers
14:16danvet: so you don't have to hand-roll this in your own driver code if you need it
14:17pcercuei: The driver is ingenic-drm, I'm working on integrating the IPU which is basically another drm_plane that can scale and convert pixel formats
14:17pcercuei: The app works perfectly fine with ingenic-drm's regular planes
14:18danvet: pcercuei, btw kerneldoc patch to fix that confusion up would be great :-)
14:18danvet: uh I wouldn't trust ingenic to be correct
14:18danvet: it has the standard copypasta vblank event handling
14:19danvet: so good chances that no one ever really thought about this
14:19pcercuei: hey, I wrote that driver ;)
14:19pcercuei: While I have you, a completely different issue
14:19danvet: the fun with vblank handling is that there's a lot more ways to get it right than wrong unfortunately :-(
14:20danvet: and we don't have good tests really, at least not for userspace
14:20danvet: and for drivers you need crc support and igt
14:20danvet: and it's really hard to hit the races in there
14:21pcercuei: if ingenic-drm's two planes (primary + overlay) are disabled, I don't get a vsync. So in that case in my crtc_atomic_check() I do crtc_state->no_vblank = true
14:21pcercuei: I expected that to be enough, but I still get a WARN() triggered because the wait-for-vblank timed out
14:23danvet: uh absolutely no vsync in that case is a bit bad
14:23danvet: userspace might also get stuck forever in its draw loop
14:24pcercuei: If both planes are disabled, chances are that userspace isn't drawing anything :)
14:24danvet: but the compositor loop is usually driven by vblank events
14:24danvet: and you might have a new frame ready that starts fading in something
14:24danvet: so that's not really what no_vblank is meant for
14:25danvet: if you claim vblank support, you better have vblank support of some sorts
14:25danvet: worst case fake it with a timer
14:25danvet: the warning itself you can paper over with a s/wait_for_vblanks/wait_for_flip_done/
14:26danvet: if you handle that case of vblank events correctly
14:26danvet: reading current ingenic code answer is probably "no"
14:35pcercuei: well, there is vblank support, just not in that one particular case
14:52sravn: danvet: did you see "Panic booting qemu-system-sparc64 with bochs_drm"
14:52sravn: I mamaged to find a hack that fixed it but not sure if this is the right way
14:53sravn: drm_fb_helper_dirty_blit_real() is only used for shadow buffers and it seems fragile to rely
14:54sravn: on shadow buffers to make it work on architectures that requires _cfb_ functiosn to access frambuffers
14:55karolherbst: mhh.. either idiv lowering is broken or the deqp test is wrong :/
15:07karolherbst: yeah.. it's broken if the divisor is a constant
15:33ric96: karolherbst: quick ques
15:33ric96: Is mesa-opencl and clover the same thing?
15:33ric96: And does the implementation works for all gallium targets?
15:34karolherbst: yes, but some drivers still need to add support for it
15:35karolherbst: well. drivers only doing TGSI won't be able to support it
15:35karolherbst: anyway.. it's not production ready yet for nir based drivers
15:36ric96: is there a support matrix available?
15:36ric96: Mostly interested in nouveau and radeon.
15:37karolherbst: no, but you wouldn't be able to use it for anything useful yet.. at least not before 20.3/21.0
15:37karolherbst: it's being worked on though
15:37karolherbst: radeon uses llvm though, so it should work...
15:37karolherbst: I just expect many bugs in their implementation
15:37danvet: sravn, no idea what to best do tbh
15:40danvet: sravn, I can imagine that we'll blow up again when the buffer is in system memory somehow
15:40danvet: e.g. for manual upload display integrated into the soc
15:40danvet: sravn, I think the full solution that was discussed was to essentially add an is_iomem bool to vmap
15:40danvet: and then wire it through
15:41danvet: fancy version would be to create an entire new pointer type which dtrt automatically
15:41danvet: but ugh
15:42ric96: karolherbst: fro what i remember only radeonsi and llvm does llvmIR and others use either just TGSI or NIR. Are the NIR devices supported then, intel for example?
15:43pcercuei: danvet: turns out my shadow register isn't a shadow register after all...
15:43ric96: Or has intel started using tgsi since move to gallium?
15:43karolherbst: tgsi is essentially deprecated and no new driver is using it
15:44karolherbst: even radeonsi uses nir these days and dropped tgsi alltogether (they still use llvm though)
15:48danvet: sravn, dev->mode_config.fbdev_is_iomem and then switching between memcpy and memcpy_toio is probably best as a quick fix
15:49danvet: since doing that full is_iomem scaffolding is way too much
15:49danvet: and also not sure how much we should bother really
15:49danvet: I don't even know whether userspace also needs to use different instructions or not for iomem
15:50danvet: so if you have a vram manager and copy stuff in&out, might need to switch depending where the buffer is
15:50pcercuei: danvet: all problems fixed now. Thanks for the help earlier
15:50danvet: pcercuei, np
15:50danvet: pcercuei, so delay the fb base addr register write and do it from your vblank irq handler?
15:51pcercuei: exactly what I did, yes
15:52danvet: sounds good
15:52danvet: sravn, maybe chat with tzimmermann too, is_iomem is halfway wired through vram helpers already
16:06sravn: danvet: will take a look at is_iomem and will try tzimmermann too
17:15austriancoder: anholt__: any update on !5510
17:16anholt__: austriancoder: haven't had a chance to dig into the request for no symlink
17:17austriancoder: anholt__: okay.. I have no rush to land the nginx thing
18:37nanonyme: Hey, are there any more concrete plans releasing xserver 1.21? Based eg description in https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/459 codebase is already diverging enough that bugfixes to distro versions are getting harder
19:18sravn: narmstrong: meson build fails in drm-misc-next when building for arm - known?
20:38airlied: nanonyme: there is nobody releasing xserver 1.21 it has no maintainer to release it
20:41nanonyme: airlied, sounds awful. Why not make 1.20 the main branch then just forget any development after that ever happened? :(
20:42nanonyme: (no, I'm not seriously for that option, there's a lot of good things post-1.20)
20:46mattst88: I'm in favor of just tagging 1.21 and see what happens
20:47airlied: nanonyme: abi breakage afaik
20:49airlied: mattst88: yeah possibly worth a go :-P
20:49mattst88: airlied: should we draw straws? :)
20:53nanonyme: airlied, hmm, ABI break in which component exactly? Something where soname can't be bumped?
20:57imirkin: presumably they mean the driver abi
20:57imirkin: bumping soname won't help - X is the thing that loads the drivers
20:58airlied: nanonyme: yeah the X driver ABI breaks, once we make a release we are committed to not changing it until the next release
20:59nanonyme: airlied, what's the implication? Out-of-tree X drivers break?
20:59airlied: nanonyme: nvidia breaks
21:00nanonyme: Yes, I was referring to that, mostly :)
21:02nanonyme: airlied, okay, so how has this thing usually been solved? Does nVidia need to ship separate drivers for both ABI's?
21:02nanonyme:hasn't been using closed source drivers for over a decade on Linux
21:03airlied: we just release a rc1 and say the abi is stable
21:03airlied: then they do whatever they do
21:03airlied: then we release the final a few weeks later\
21:04airlied: and try not to break the abo
21:05nanonyme: I was referring to the fact they will then for a couple of years target distros with either of the two ABI's with their blobs
21:05nanonyme: (or maybe longer in case of LTS distros)
21:06airlied: nanonyme: oh they just do some internal magic that means it can run on lots of xservers
21:06airlied: they have some abi abstraction or something I assume
21:08nanonyme: Doesn't sound like an impossible task then. Of course, there's still the question of which MR's it makes sense to still get in since making these releases is apparently such a PITA :)
21:09airlied: the question is more how bad a state is master in
21:09airlied: the modesetting driver's attempts at using modifiers and aotmic modeseting have both kinda been sub-par
21:11nanonyme: Does it have these in 1.20? Can the features be defaulted off?
21:12airlied: I think maybe they are off now, but it's more the quality of other things if those were so bad
21:13karolherbst: airlied: seems like james is working on fixing at least the modifier stuff in X
21:13karolherbst: but yeah
21:13karolherbst: modifier stuff seems to be horribly broken
21:13airlied: releasing the X server needs someone willing to kick people into fixing things
21:13karolherbst: it's so broken, nouveau doens't work with 5.8 apparently
21:19nanonyme: airlied, I at least am in no position to kick anyone into doing anything. I've just been gently poking annually to try to see what's going on. Would it help if there was more testing on the codebase or is it more a development manpower thing?
21:20airlied: it's more of a who cares enough :-P
21:20nanonyme: And just after saying that comment I realized that word is probably one of the ones that will be on its way out
21:21airlied: at the moment the care factor is 0 in terms of someone being in a position to release and having time and employer support to do so
21:22airlied: ajax has made it pretty clear he doesn't want to do another release, the rest of our team at RH is having a hard time caring about anything non-Xwayland
21:23nanonyme: airlied, XWayland suffers of quirks until https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/195 is out
21:24airlied: yup so maybe someone like ofourdan or MrCooper will kick a release, but currently there isn't a massive amount of motivation to do so
21:25airlied: but maybe mattst88 is right and we just should just trhow rc1 out there and see what sticks
21:34danvet: airlied, atomic in 1.20 is the horror
21:35danvet: 1.21 would actually be fixed I think, except no one merged the patch to re-enable the atomic goodies now that the kernel refuses to hand them out
21:35danvet: it's imo all pretty hopeless
21:35danvet: modifiers always have been disabled by default iirc
21:36danvet: maybe we should do an Xwayland only release
21:36danvet: or something like that
21:36mattst88: and so modifiers are likely to be broken if we release xserver-1.21?
21:40narmstrong: sravn: not expected, can’t check right now
21:44danvet: mattst88, as broken as before
21:44danvet: as long as you don't change the default it's ok
21:45danvet: otherwise I'll type a kernel patch and remove them for compositors called X
21:45danvet: like with atomic
21:46nanonyme: If it's not a regression, it at least wouldn't break anyone's workflow that isn't already broken...
21:46danvet: nanonyme, atomic was enabled by default in X
21:47nanonyme: danvet, I was meaning modifiers
21:47danvet: so when more kernel drivers started supporting atomic, we had no choice than to outright disable it
21:47danvet: nanonyme, yeah but if anyone gets frisky and enables modifiers by default, the same will likely happen
21:48nanonyme: Ugh. You mean like distros?
21:48danvet: modifiers did already blow up for nouveau
21:48danvet: worksforme isn't good enough testing for the kernel's "no regressions" policy
21:49nanonyme: Would it be possible to hide it behind some build flag so it's more obvious you must not enable it unless you're a developer?
21:50mattst88: danvet: I'm confused. do you think 1.21+reenable atomic is better/equal/worse than 1.20?
21:51karolherbst: nanonyme: some distributions just enable shit because they like the sound of the feature :p
21:51karolherbst: sometimes even pick patches not even merged
21:51imirkin: like the one that forces the use of modesetting over nouveau ddx in RH and Debian?
21:51karolherbst: I think some even included patches from imirkin which said "don't include" :p
21:52karolherbst: imirkin: I was more thinking about your multithreading patches
21:52imirkin: yeah, some people tried to include my busted multithreading fix patches
21:52imirkin: i had to take those offline and probably ended up losing those.
21:52imirkin: o well.
21:52danvet: mattst88, there's no real benefit to the atomic code in 1.21
21:52danvet: so if no one works on that, it really doesn't matter
21:52danvet: but from looking at it, it seems at least a lot less broken than 1.20
21:53mattst88: danvet: earlier you said '1.21 would actually be fixed I think, except no one merged the patch' though?
21:53danvet: mattst88, the atomic code _seems_ fixed, I didn't validate all the corner cases (vkms still isn't good enough for that, and I don't care)
21:54danvet: it's just that the fixed atomic code wont run, because the kernel doesn't advertise atomic if your called "X"
21:54danvet: would need a -modesetting patch to get atomic back for X (just ask for atomic v2)
21:55danvet: but given that the current atomic code in -modesetting does not do a hole lot more than legacy kms
21:55danvet: not sure anyone cares to type the patch, get it tested, properly reviewed and merged
21:55danvet: plus fix up the fallout
21:55danvet: I think what you get is with atomic better pageflip between different formats
21:56danvet: but hey without modifiers enabled that's not that useful
21:56karolherbst: what I am wondering about here: why care about X anyway... there are already use cases where wayland is the only way out.. even with the nvidia driver
21:57karolherbst: if you have two displays with different DPI, the only think you can use is wayland anyway
21:57danvet: yeah hence maybe do Xwayland releases only
21:57karolherbst: and I don't see a stronger argument _for_ X than this
21:57karolherbst: danvet: right
21:57danvet: avoids all the headaches with hw drivers
21:57danvet: and for Xwayland maybe we can get modifiers going eventually
21:58danvet: so having an Xwayland release train would be nice I think
21:58nanonyme: If that's doable and that contains the MR I mentioned earlier, that sounds awesome
21:59nanonyme: I don't really personally care about X11, jus XWayland
21:59mattst88: my users were angry enough when we switched from setuid to depending on logind *by default*
22:00mattst88: I'm imagining a lot more angry users if we stop shipping /usr/bin/Xorg
22:02nanonyme: But anyway, doing that still also really begs the question of whether there's intent to ever release the whole and if not, does it make sense to do fixes to master and backport when master will never be released?
22:03nanonyme: I'm assuming no one does same fixes to two somewhat different branches just for fun
22:09nanonyme: Just a thought. My personal itch is just getting the XWayland fix available
22:12mattst88: nanonyme: what fix? https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/459 ?
22:12airlied: in theroy llvmpipe will expose multisample now
22:13mattst88: nanonyme: that's the backport, so we can just merge that and make a 1.20.x release. no need to sort out what to do about 1.21
22:44karolherbst: airlied: that sounds like... fun?
22:44karolherbst: but is it properly implemented or is it just faked?
23:05airlied: karolherbst: implemented properly
23:09karolherbst: okay, cool
23:10karolherbst: I just know some games enabling msaa without giving users a chance to disable it, but I doubt anybody will use llvmpipe for games anytime soon anyway :p
23:10karolherbst: though.. modern CPUs might be capable
23:18airlied: not for many games :-P
23:28dcbaker[m]: mattst88: can you imagine what certain sites would say about dropping /usr/bin/Xorg? Lol
23:28mattst88: dcbaker[m]: rabid cheering?
23:29dcbaker[m]: Either that or is the end of the Linux desktop
23:30dcbaker[m]:is amazed how bad the Android keyboard is
23:30mattst88: I am expecting a rage-inducing forum argument with idiots supporting both positions
23:33dcbaker[m]: Inducing or induced?
23:33dcbaker[m]: Either way, I think this is a job for ajax , after all, deleting the xserver is pretty much a divine mandate for him
23:34iive: llvmpipe is used mainly for debugging... checking if device driver has the same bug.
23:40mattst88: dcbaker[m]: to quote ajax, "can't it be both?"