01:47 dcbaker[m]: wow those instructinos are old
01:47 dcbaker[m]: set your exports and run `glxinfo`, you can look at the version info to see if you have the version you expect
02:10 dcbaker[m]: these are probably better: https://docs.mesa3d.org/meson.html
07:20 jpsollie: Hello everyone, I have a question about mesa 20.3: several sites mention it supports opencl 1.2. As clover is about 10x faster and way more stable on my PC compared to ROCm, I'd like to use that one for folding@home. However: clinfo does not show 1.2 conformance, only 1.1. What's the problem here? does it support 1.2 or not?
07:25 jpsollie: and to show the opencl performance, I used a modified version of opencl-benchmark on github, where date +%%%s.%N%% && ./a.out && date +%%%s.%N%% showed the following for clover:
07:25 jpsollie: %1607525926.138453752% Result: 11168608085589920491 Runtime: 0.000700ms %1607525950.744559860%
07:25 jpsollie: for rocm, this becomes:
07:25 jpsollie: %1607670999.627702896% Result: 11168608085589920491 Runtime: 0.012555ms %1607671024.114541166%
07:27 jpsollie: The execution time is almost the same, but the GPU runtime is more or less 12x higher on rocm, so I'd obviously prefer clover
07:29 airlied: jenatali: not sure where you saw that but it doesn't support 1.2 yet
07:30 airlied: oops
07:30 airlied: jpsollie: ^
07:31 airlied: if you don't want images or printf, you can use CLOVER_DEVICE_VERSION_OVERRIDE=1.2 and CLOVER_PLATFORM_VERSION_OVERRIDE=1.2 CLOVER_DEVICE_CLC_VERSION_OVERRIDE=1.2
07:32 jpsollie: @airlied: on phoronix
07:32 jpsollie: https://www.phoronix.com/scan.php?page=news_item&px=Mesa-20.3-OpenCL-1.2-Clover
07:33 jpsollie: a fiji gpu supports 1.2, so I thought it's OK
07:33 airlied: those were just prep work for 1.2
07:34 airlied: 1.2 apps that don't need printf or images should work with overrides
07:34 airlied: but clover needs a lot more work all over before it's a decent CL implemtation
07:35 jpsollie: ? so why is it that much faster then? I know many people don't like clover too much because it's a bit outdated, but these are promising results, no?
07:36 airlied: yeah if the results are correct, I've no idea why it's fast than rocm though
07:37 airlied: clover is hopefully going to to be a CL 3.0 implementation at some point and be more useful
07:37 airlied: but that isn't yet, maybe in 3-6 months
07:37 jpsollie: any chance it will be with mesa 21.0?
07:38 airlied: for amd cards 21.0 might get 1.2 without images
07:39 jpsollie: so in meantime, I'd better start reporting bugs @ rocm guys? (yes, I'm talking about bugs becuse it's not even close to stable)
07:40 airlied: I've no diea idea if rocm folks even had a bug tracker :-P
07:40 airlied: I'd like to just get a useable opencl baseline in mesa across all linux open source drivers, then figure out the bigger problem of tackling rocm :-P
07:42 jpsollie: well, that's encouraging ... so I'll develop my apps in opencl 1.1 for now, and wait for opencl 1.2 in clover in 2021 (hopefully) :)
08:33 kusma: airlied: awesome!
08:48 MrCooper: is this some kind of prank? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8048
08:48 MrCooper: (also, really, random users can approve MRs?)
08:52 airlied: MrCooper: i did wonder,
08:52 airlied: MrCooper: whyskip slow tests only one hits timeout badly i might add a skip but not back to a pc for a week
09:08 airlied: MrCooper: hmm one of the texturing tests might need adding to flakes or skips
09:08 airlied: seems to timeout as well, they never take that long locally
09:09 danvet: MrCooper, it's self-approved even
09:10 danvet: maybe that button just isn't useful in gitlab ce
09:11 pepp: CI logs say "Test dEQP-VK.texture.filtering.3d.sizes.3x7x5.linear_mipmap_linear: Timeout: See "/builds/mesa/mesa/results/c51.r1.qpa" but this file isn't in the artifacts (from https://gitlab.freedesktop.org/mesa/mesa/-/jobs/6115828)
09:12 danvet: emersion, sent you the mesa/drm invite
09:13 airlied: anholt, MrCooper : for next 7 days feel free to disable lvp CI if needs be, dont wait for me
09:15 MrCooper: understood
09:19 danvet: emersion, threading broke btw
10:04 danvet: tzimmermann, pretty sure we can't merge your udl and gm12u320 before at least all major gpu drivers have vmap_local support
10:04 danvet: the other conversions are probably ok
10:05 tzimmermann: danvet, i see.
10:05 tzimmermann: i'll split this up into per-driver patches, and i'll have to check what the other drivers need.
10:06 tzimmermann: but this won't happen before jan 21
10:06 tzimmermann: anyway, that's for these reviews
10:06 danvet: maybe also double check there's not another path from the new vmap_local back to dma_buf_vmap
10:06 tzimmermann: i guess this will become multiple patchsets
10:07 danvet: hm should be still fine as one
10:07 danvet: the driver conversions looked entirely optional
10:08 danvet: but yeah maybe split out the minimal parts for fbdev
10:08 tzimmermann: danvet, can you also look at patches 1 and 2. they are independent from vmap_local and should go in anyway
10:08 danvet: oh right I wanted to slap an acked-by on the remaining bits but then realized the compat issue for buffer sharing with extended desktop
10:11 tzimmermann: hmm, well yeah, i guess the driver conversion is optional. the udl and gm12u320 plus the missing drivers' vmal_local can go in later
10:12 danvet: tzimmermann, I just realized another problem, but it's kinda preexisting I think
10:53 emersion: danvet: thanks!
10:53 emersion: danvet: yeah… i'll just switch to another SMTP server i think
12:24 tomba: dim push wants the links to the patch mail in the commit description, which is automatically added with dim apply. Are there any magic tricks to manage the links with a big series, where you do minor changes to patches? I have 81 patches, and some of the earlier ones in my branch have some whitespace cleanups or such, so I don't want to pick the patch from the mailing list. Or should I just send the 81 patches to be able to dim apply
12:24 tomba: them, and apologize for the spam?
12:26 ccr:waits for tomba's batmud patch sets.
12:28 tomba: waht? =)
12:28 ccr: nevermind, just joking around. :P
12:29 tomba: you may have a long wait, I don't think I have even logged in to batmud for 10 years =)
12:30 ccr: I checked, last time was 6 years ago or so!
12:32 tomba: well, I stand corrected =)
12:33 ccr: :)
12:50 dolphin: tomba: not sure I followed, why would you modify patches you used dim apply on?
12:50 dolphin: you should use git am for applying the series until you intend to merge
12:54 tomba: dolphin: So I have sent the patches to the list. Then I make some whitespace fixes. Should I just resend, or dim apply the patches from the list, and modify the applied patches? The latter becomes easily difficult.
12:54 tomba: Normally I would just resend, but 81 patches is a bit on the spammy side
12:54 dolphin: ok, now I understand
12:56 dolphin: well, it gets extra CI coverage (81 patches sounds like major series), so I would err on the side of following the process
12:56 tomba: so in theory, I think a smart script could go through my commits, find the latest matching posts in the list, and add the link accordingly. It's cheating a bit, but if the changes are trivial whitespace/etc, I don't think anyone would mind.
12:56 dolphin: well, the thing is that we don't trust humans with doing trivial fixes
12:57 tomba: dolphin: yes, I think I agree. Sam just complained about the spam a bit in an earlier version, so I thought I'd see if there's an easy way to avoid it =)
12:57 dolphin: accidentally paste something to your terminal (how many :wq or :q! have we seen in patches)
12:57 dolphin: not sure that tells more about vi than the users, but anyway
12:57 dolphin: you can use omit-cc git option
12:58 dolphin: for just whitespace fixes, that should be fine
12:59 tomba: yep. thanks!
13:24 dschuermann: anholt: I'd like to merge !6666. any update on the blocking issue?
14:02 danvet: emersion, your patch submissions still don't thread correctly
14:03 danvet: do you have threading disabled somewhere in git config?
14:03 danvet: it should be the default iirc
14:03 emersion: yea yea it's an issue with my smtp server
14:13 MrCooper: it drops In-Reply-To/References headers?
14:13 MrCooper: or messes with Message-ID?
14:14 emersion: messes with Message-Id
14:14 Sumera: danvet: Is there any way I can browse the repo at the time the old patch was sent? Apart from just correlating the date and switching to the latest release by that date. Would help me get me a little bit more context for the parts of the file that are not in the patch.
14:15 sravn: tomba: for trivial fixes I just do them and apply. The link point to the mail with the discussions which are important, it is not that the patch are 00% the same
14:15 danvet: Sumera, not really except by asking the original contributor whether they have that tree still somewhere
14:15 danvet: it's another reason why this patch process isn't so great
14:17 danvet: emersion, and we signed you up for mailman admin :-P
14:17 emersion: yeah :S
14:25 Sumera: danvet, Ah, no worries, I will trim whatever I can't figure out for now.
14:40 tomba: sravn: Right. But I don't have the links in my work branch where I have the minor changes. I could dim apply the posted patches, and the try to re-do the changes to those, but that would be somewhat difficult (especially as git diff doesn't show commit desc changes). So I think I'll just resend, and say sorry for the spam =).
14:46 danvet: Sumera, if you're stuck just ping me
14:46 danvet: or ask siqueira here for the original tree
14:56 Sumera: danvet, sure.
15:23 agrisis: hello, it looks as though systemd manages the graphics system and may handle drmDropMaster and related stuff to switch ttys while an app is using drm/kms
15:24 agrisis: On systems without systemd, is there any way to make this achievable?
15:25 pq: agrisis, yes: very painfully implementing the same in your KMS program (which may also require root privileges). Or, maybe one of the logind replacements can do what systemd-logind does.
15:25 danvet: s/may//
15:25 danvet: well CAP_SYS_ADMIN
15:25 pq: danvet, what exactly needs CAP_SYS_ADMIN?
15:25 danvet: setmaster ioctl
15:26 pq: no, not anymore?
15:26 danvet: which is hilarious, because if you win the race and open first, you get it for free
15:26 danvet: oh
15:26 pq: didn't Emil patch that out?
15:26 pq: so if you ever were a drm master, you can be again without root/admin
15:27 danvet: ah right it's more tricky now
15:27 danvet: if you lucked out and got master at open time
15:27 danvet: you can set/drop on your own
15:27 pq: yeah, for that case exactly
15:27 sravn: tomba: Yeah, if it is only for a few patches you could hand-edit the link (copy it), but spam us and get it over. For some reason most of your mails hits my spam filer anyway
15:28 agrisis: pq: it seems elogind doesn't implement this unfortunately
15:28 pq: which is almost guaranteed if you start your KMS program from a VT shell prompt?
15:28 danvet: pq, well something else could start
15:28 danvet: or still be running
15:28 danvet: or whatever
15:28 pq: danvet, does running but not anymore master -think count?
15:28 pq: *thing
15:29 danvet: no
15:29 danvet: so yeah the cooperative vt dance should work better with this
15:29 agrisis: my use-case is having my drm app on tty1 but I'd like to switch to a agetty tty2 (non-drm) which currently does not work. I assume my app will need to listen to the tty switch notification and then drop drmMaster?
15:29 pq: good, so if you're staring at fbcon shell, and manually launching your KMS program, it should work pretty much
15:30 pq: agrisis, yes, and a lot more.
15:30 agrisis: I guess it's too bad mingetty or agetty don't implement this
15:30 danvet: yup, a lot more
15:30 agrisis: gosh...
15:30 danvet: vt switching is kinda tricky
15:30 danvet: there's a reason logind is the right solution for this problem
15:31 danvet: or something like logind
15:31 pq: agrisis, also depends on how you handle input.
15:31 danvet: yeah input has a similar concept
15:31 danvet: plus there's some vt fiddling to be done too
15:31 agrisis: unfortunately my distribution doesn't support systemd
15:31 agrisis: would fbcon help me?
15:31 danvet: yeah then you get brittleness and shellscripts
15:31 danvet: nope
15:32 danvet: but fbcon is the reason you need to do some vt fiddling too
15:32 danvet: otherwise fbcon will get you
15:32 agrisis: I'm also on kernel 4.4 so will most likely need root privileges too
15:32 pq: agrisis, Xorg, Weston, and I bet other Wayland compositors too implement what you need. Which one is a good example... probably none.
15:34 pq: https://gitlab.freedesktop.org/wayland/weston/-/blob/master/libweston/launcher-direct.c is one way to handle things in a certain situation
15:34 danvet: if you really want to not use system, best would be to port this to elogind
15:34 danvet: but it might terminally upset the systemd haters camp because it's not brittle shells scrips :-)
15:35 pq: weston also has 'weston-launch' setuid-root helper program and launcher-weston-launch.c to go with that.
15:35 agrisis: https://retropie.org.uk/forum/topic/26477/how-does-emulationstation-go-around-the-need-from-drmsetmaster-drmdropmaster/2
15:36 agrisis: I might be able to glean something from that
15:38 pq: agrisis, mind that some aspects of VT setup might also require root.
15:39 pq: but what exactly, I can't say
15:44 vsyrjala: you don't need root but you do need (write iirc) access to at least /dev/tty0 if you want to do a vt switch
15:46 agrisis: https://github.com/RetroPie/RetroPie-Setup/blob/master/scriptmodules/supplementary/runcommand/runcommand.sh
15:46 agrisis: looks like that is doing it somehow, I'll dig into it a bit
15:47 agrisis: I tried EmulationStation on my device and indeed it seems to work
15:47 amonakov: I had a related Q - if I'm logging in via ssh, how can I start an X server that would be gpu-accelerated (but not bound to a physical output)?
15:49 pq: vsyrjala, yeah, opening /dev/tty0 usually fails.
15:49 vsyrjala: i used to run XDirectFB w/o a vt switch, which iirc didn't need any magic permissons. but consolekit or something didn't work right when i had both a console session and gui session on the same tty, so i had to start doing a vt switch, which annoyingly requirs extra perms :(
15:50 pq: vsyrjala, yeah, if you can open the KMS node and get master, you can clobber stuff, and VT will just malfunction :-P
15:50 pq: without extra code to do the VT dance that needs extra permissions
15:51 pq: it's like... screwed up by default
15:51 zmike: is there a script people use to generate Fixes tags on commits? seems silly to keep manually copy/pasting like I have been
15:51 zmike: (for mesa)
15:51 pq: amonakov, um... Xvfb? Dunno about the accel part.
15:52 pendingchaos: zmike: I have this in my .gitconfig: https://pastebin.com/raw/ndrhRpKm
15:52 pendingchaos: then I can do "git fixes <sha>"
15:53 zmike: hnnnnnnnnnngggggggg
15:53 zmike: pendingchaos: thanks!
15:53 pq: agrisis, did you read the forum post you linked to? It said SDL handles all the KMS/VT stuff for them.
15:55 pq: agrisis, a shell script for handling VT switching for a KMS app definitely seems like a bad idea.
15:55 vsyrjala: iirc if you don't need a vt switch all you really need is KD_GRAPHICS on the current tty
15:56 agrisis: pq: yes I saw that but wanted to dig in further to confirm
15:56 pq: vsyrjala, yeah, but that doesn't stop people from trying to VT-switch, does it? And then it explodes?
15:57 pq: agrisis, one example of pitfalls here: if you get input setup wrong, your keyboard typing could be going to the VT (even to a shell) *and* to your KMS app at the same time. :-)
15:58 vsyrjala: can't remember what hapens if you don't hook up the vt switch signals
15:59 pq: vsyrjala, I think the kernel VT switching keys continue to work in that case. And they switch. But your program doesn't know, and it doesn't use the VT for output either.
16:00 pq: your program might lose input if it relied on VT input, but remain on screen otherwise
16:00 pq: if your program opened input devices, it won't even lose input, but quite likely the keyboard input is duplicated to both the program and the VT
16:01 agrisis: this seems nightmarish without logind
16:01 pq: agrisis, correct. It is.
16:02 pq: the VT system is one of the oldest pieces of Linux, I think, and it cannot be fixed because *touching* it would break something as every program from the last couple decades uses it slightly differently
16:02 agrisis: agreed
16:02 vsyrjala: VT_SETMODE doesn't seem to need access beyong the current tty. but the man page is very unhelpful in telling if there's a way to just prevent vt switching
16:03 emersion: agrisis: might be interested in seatd
16:03 emersion: https://git.sr.ht/~kennylevinsen/seatd/
16:03 agrisis: there must be a userspace helper somewhere where you can force it
16:05 agrisis: emersion: interesting, thanks
16:05 vsyrjala: change_console() says "Ignore all switches in KD_GRAPHICS+VT_AUTO mode". so looks like just KD_GRAPHICS+VT_AUTO is enough to prevent vt switching
16:05 emersion: there's libseat in the box, which works with systemd, elogind, seatd, and standalone
16:07 kennylevinsen: vsyrjala: yeah, that's a common "VT deadlock"
16:07 agrisis: I'll have to read up on this
16:08 agrisis: emersion: do you suppose I will need to integrate the client-side of this into my drm app or should tty switching just work if seatd is running?
16:08 kennylevinsen: A lot of projects have workaround to escape it. The other way of blocking switching is process control where the registered process is alive and does not ACK the switch
16:08 vsyrjala: kennylevinsen: yeah, i have a small program around that sets things back to KD_TEXT after whoever that used KD_GRAPHICS exploded
16:09 vsyrjala: annoying Xorg just hangs if the you try to start it while already in KD_GRAPHICS
16:09 emersion: agrisis: the daemon approach always needs client-side support, be it systemd, elogind or seatd
16:10 emersion: because clients need to talk to the daemon instead of the kernel
16:11 agrisis: right
16:27 danvet: tzimmermann, apparently next-fixes isn't rolled forward?
16:27 danvet: narmstrong at least just complained on dri-devel
16:28 narmstrong: danvet: oh wasn’t complaining
16:28 danvet: well you can't apply patch
16:29 danvet: so maybe I'm complaining so you can apply patch again
17:02 sravn: danvet: drm/vkms: Unset preferred_depth - s/ix/is/ in FIXME comment
17:03 danvet: uh I pushed it already ...
17:03 danvet: one for the typo police maybe :-)
17:04 sravn: Wondered if this was some slang
17:22 tzimmermann: danvet, that can be fixed by backmerging drm-next?
17:33 anholt: dschuermann: I thought since there was a regression it was up to you at this point
17:34 dschuermann: anholt: can we try to find a reviewer for your MR? it's a bit of a bummer that it blocks something unrelated
17:34 anholt: dschuermann: can you just merge mine in and try?
17:36 dschuermann: you mean testing !7658 on radv? because !6666 cannot be tested on radv without a bunch of other MRs
17:36 anholt: dschuermann: no, I was saying that !6666 regressed softpipe, which should be easy to test
17:37 dschuermann: oh, I over-read that. I have never used softpipe °°
17:38 anholt: -Dgallium_drivers=softpipe, LIBGL_ALWAYS_SOFTWARE=1 GALLIUM_DRIVER=softpipe should do it
17:38 anholt: -Dgallium-drivers=swrast I mean
17:42 anholt: picking !7658 back up again, need to get it sorted for !8044
17:45 danvet: tzimmermann, uh no
17:46 danvet: once the last -next pull is out for the merge window you need to roll -misc-fixes forward to whatever that is
17:46 dschuermann: anholt: and which shaderdb test cases?
17:46 danvet: oh I read drm-misc-next
17:46 danvet: tzimmermann, yeah backmerge works too
17:46 anholt: oh, no, did I not note it? I'd have to rerun to find out.
17:46 danvet: well it should be still a fast-forward
17:47 anholt: in the middle of fixing up liveness
17:47 danvet: tzimmermann, but in general best to do that right away when the last -next pull has gone out for that merge window
17:48 danvet: so that people can apply bugfixes to the right tree right away again
17:49 danvet: also that prevents drm-misc-next from going into linux-next
17:49 danvet: which it shouldn't, since that stuff in there is for the next merge window
18:22 mattst88: emersion: IIRC I asked back in June about a wayland release. are we going to do that sometime this year?
18:25 mattst88: 9 months to get a release with my wayland-scanner commits isn't great :(
18:26 emersion: hm, i don't remember. but i was planning a release yesterday
18:59 anholt: dschuermann: !7658 should be in good shape now
19:01 tzimmermann: danvet, thank you. i'm about to fast-forward. is there special tooling or is it just 'git merge --ff-only <latest-tag-in-next>' ?
19:02 danvet: it's just that
19:02 tzimmermann: ok
19:04 tzimmermann: narmstrong, danvet, -next-fixes should be ready now
23:29 Andrew_R: oh, now wine drops me "X Error of failed request: GLXBadFBConfig" (on X server 1.19.7 + latest mesa git)