00:00 bnieuwenhuizen: Thanks!
00:19 SolarAquarion: bnieuwenhuizen: that was fast, lmao
00:22 karolherbst:thinks running the CTS just like that is only for beginners, pros run it compiled against libasan with mesa also compiled against libasan
00:23 bnieuwenhuizen: hmm, I have never tried running Vulkan-CTS with asan
00:24 bnieuwenhuizen: karolherbst: how do you make sure dependencies are compiled with asan?
00:25 karolherbst: bnieuwenhuizen: doesn't matter
00:25 bnieuwenhuizen: well, that is easy :P
00:25 karolherbst: if you have one library you have to make sure to preload it, but if a binary was compiled against it, it will just load it :p
00:25 karolherbst: s/binary/executable/
00:26 karolherbst: bnieuwenhuizen: :D
00:26 karolherbst: let's say.. the CTS has a weird way of using sizeof
00:26 karolherbst: bnieuwenhuizen: https://github.com/karolherbst/VK-GL-CTS/commit/36a13458342d53608abd1ffd950b620edbd343b1
00:26 karolherbst: but there are a few more issues
00:27 karolherbst: anyway.. just wanted to get rid of all memory corruption bugs inside the CTS and mesa to at least get rid of those annoying fails
00:27 karolherbst: like running the CTS for hours just so that something fails in the 50th iteration or so
01:00 SolarAquarion: i'm getting a segmentation fault, but that may be because of ld
01:01 SolarAquarion: gnu ld
02:35 SolarAquarion: got a crash backtrace thanks to lld https://paste.debian.net/plain/1157371
02:36 SolarAquarion: something is going on with OSMesa that's causing the linker to crash at that point
03:08 dcbaker[m]: Are you using lto?
04:10 airlied: jekstrand: any reason anv doesn't use I915_EXEC_BATCH_FIRST?
04:14 airlied: ah I guess the batch bo can be anywhere in the list
04:26 jekstrand: airlied: Because it doesn't really buy us anything. It's easy enough to swap two things.
04:27 jekstrand: And, since we have to carry the swapping code anyway....
04:28 airlied: jekstrand: I just thought it was always swapping 0 and last, but I'm not sure the code guarantees it's at 0 in the first place
04:29 jekstrand: airlied: It doesn't
04:29 jekstrand: airlied: In fact, I'm pretty sure we put state pools first.
04:29 jekstrand: It's ok, one of these days VM_BIND is going to be a thing and then there will only be one BO in the list so it won't matter. :)
04:33 airlied: vm_bind over uring :-P
07:00 MrCooper: tomeu: looks like some of the new traces might be flaky: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/3735818
07:45 tomeu: MrCooper: cool, those are interesting artifacts, thanks
07:48 tomeu: MrCooper: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6023
08:18 icecream95: With panfrost, MSAA works for anything using EGL, but not GLX - glxgears -samples 4 fails with "couldn't get an RGB, Double-buffered, Multisample visual"
08:18 icecream95: Any ideas for what needs to be changed or where to investigate? glxinfo doesn't show any multisample visuals.
08:21 daniels: ajax: ^
08:32 MrCooper: icecream95: which version of which X server?
08:36 icecream95: MrCooper: Both X and Xwayland, 1.20.8
08:36 MrCooper: with Xwayland it can only work with xserver Git master
08:36 MrCooper: Xorg should work though, assuming its glx module can find the DRI driver
08:38 MrCooper: grep the log file for "AIGLX"
08:39 icecream95: AIGLX: Loaded and initialized rockchip, AIGLX: Screen 1 is not DRI2 capable
09:09 MrCooper: the latter is likely related; would need to drill down why DRI2Connect returns FALSE
09:10 icecream95: MrCooper: That seems to be related to fbdev - I uninstalled xf86-video-fbdev and it doesn't appear anymore
09:11 MrCooper: hmm, can you pastebin the full Xorg log file and the output of glxinfo?
09:18 icecream95: MrCooper: https://gitlab.freedesktop.org/snippets/1111/raw
09:25 MrCooper: there are no GLXFBConfigs with multiple samples, looks like you need to dig into that in Mesa after all
09:26 daniels: I wonder if we need to expose a higher GL version at some level?
09:26 MrCooper: maybe
09:27 daniels: icecream95: how about MESA_GL_VERSION_OVERRIDE=3.1?
09:30 MrCooper: daniels: lots of 'Branch cannot be merged' again since yesterday, maybe the workaround isn't that effective after all :(
09:32 daniels: urgh
09:36 MrCooper: worth trying an even longer sleep, say 60s?
09:37 daniels: mmm, that could help in some cases, but given there's a cache in play, it doesn't just rely on the background job (when CI completes, trigger a background job to check if the MR is now mergeable) to complete, but also something to invalidate the cache
09:38 daniels: but sure, if you spin a new container with 60sec then I'll apply that - it's no worse than what we already have
09:41 icecream95: It looks like my LD_LIBRARY_PATH isn't getting set for the Xorg process - where do I set environment variables for Xorg?
09:48 MrCooper: icecream95: note that LD_LIBRARY_PATH won't affect where Xorg's glx module loads rockchip_dri.so from
09:49 MrCooper: need LIBGL_DRIVERS_PATH for that
09:59 icecream95: MrCooper: Where do I set them? Putting them in /etc/environment doesn't have any effect
10:00 MrCooper: I'd expect that to work, check in /proc/<Xorg PID>/environ
10:05 icecream95: MrCooper: /proc/`pidof Xorg`/environ only has PWD, SHLVL and PATH
10:07 MrCooper: in the worst case, rename the Xorg binary and replace it with a wrapper script which exports the variables and then execs the real Xorg
10:12 icecream95: MrCooper: /usr/bin/Xorg is already a wrapper script, so I just exported LD_LIBRARY_PATH and LIBGL_DRIVERS_PATH in there and now MSAA works :)
10:13 MrCooper: \o/
10:15 daniels: woohoo
10:15 karolherbst: mhh.. this TGSI seems pretty invalid to me: https://gist.githubusercontent.com/karolherbst/45584c8f36070ce84c2deacdb7c6102d/raw/2e66a837c016daffed34fcc69b19c0be2f17dfc6/gistfile1.txt
10:16 karolherbst: "TEMP[7]" accesses
10:19 karolherbst: "double array[1];" in glsl ...
10:20 karolherbst: but that still looks fine..
10:27 MrCooper: daniels: pushed a new 0.9.2-sleep-60 tag to https://gitlab.freedesktop.org/daenzer/marge-bot/container_registry
10:53 daniels: MrCooper: running now, ta
10:54 MrCooper: thank you
10:54 MrCooper: tomeu: another possibly flaky trace: https://gitlab.freedesktop.org/GL/mesa/-/jobs/3739208
11:03 icecream95: tomeu: panfrost-t760-traces only seems to fail with rk3288-veyron-jaq-cbg-0
11:07 daniels: icecream95: it works reliably on -1?
11:10 icecream95: daniels: it appears so
11:12 karolherbst: is there any way of properly debugging glsl_to_tgsi?
11:12 karolherbst: *debug
11:18 daniels: icecream95: uhh
11:22 daniels: goddamn, you're right. every execution of demo.trace on cbg-0 has killed the GPU; every execution of demo.trace on cbg-1 has succeeded
11:24 daniels: tomeu: ^ can we please temporarily remove pathfinder demo.trace from the rotation (your 'flaky-trace' branch removed the next one down in the list instead) until we can figure out why that is?
11:25 daniels: I wonder if there's some bizzare kind of silicon revision thing going on; I don't think it can be power since they both run through dEQP totally fine, and it's not anything else environmental since they're on the same rack with the same config, plus I'd expect power/memory/whatever issues to manifest much more randomly throughout runs, not specifically always on one trace
11:32 HdkR: fee
11:32 HdkR: ...yes
11:59 haasn: https://0x1.st/5.txt wow, now there's a new one
12:02 bnieuwenhuizen: haasn: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3242 ?
12:03 haasn: neat, thanks
12:04 haasn: I'll revert that commit until the gcc update is out
12:08 tomeu: daniels: I think I would disable traces on 760 for now
12:09 daniels: tomeu: so weird that it seems to only be the one pathfinder trace though?
12:10 tomeu: daniels: yeah, I can only think that we have a race there
12:11 tomeu: daniels: pathfinder/canvas_moire.trace also gets misrendered tiles
12:11 daniels: blurgh
12:11 daniels: but why only -0 and not -1 ...
12:16 HdkR: Broken memory? Not terribly uncommon :)
12:21 daniels: HdkR: it's _way_ too deterministic for broken memory
12:21 daniels: (if you ask me)
12:22 daniels: I mean, it runs all the way through 6-way parallel dEQP tests, but only ever fails on one very specific trace ... ?
12:30 MrCooper: tomeu: disabling traces on 760 for now sounds good, otherwise we might have to revert the new traces for now, as it's preventing other MRs from merging
12:31 tomeu: ok, it's in Marge's hands now
12:36 haasn: why does mesa vendor vulkan headers/xml instead of using /usr/include/vulkan?
12:36 haasn: this is causing me issues on latest master, because the mesa vulkan headers are out of date relative to the loader
12:36 haasn: (segfault)
12:38 imirkin: haasn: what if the system headers are out of date? mesa won't compile...
12:38 imirkin: also how could system headers being newer cause segfaults?
12:39 haasn: imirkin: they added a new enum member in the middle of the enum
12:39 imirkin: haasn: they're not supposed to do that
12:39 haasn: I know
12:46 haasn: https://github.com/KhronosGroup/Vulkan-Headers/pull/135 I guess
12:46 gitbot: KhronosGroup issue (Pull request) 135 in Vulkan-Headers "Fix enum order for backwards compatibility" [Open]
12:50 imirkin: haasn: this has nothing to do with mesa's vendoring, right? if you had a mesa built with old headers and an application/loader compiled with new headers, you'd get the same issue, no?
12:51 SolarAquarion: dcbaker: yes
12:51 SolarAquarion: i didn't activate lto
12:51 haasn: imirkin: yeah, I namedropped mesa because it's an example of something nontrivial affected by this where the work-around involves "manually patching vulkan-headers"
12:52 imirkin: seems like it would affect blob drivers even harder
12:52 imirkin: since they're not as easy to patch
13:34 haasn: https://0x1.st/0.txt also seems to be necessary
13:34 haasn: what a mess
13:38 imirkin: or just dump it into the enum so you don't have to forget next time?
13:38 imirkin: oh right - this is in mesa, nevermind
13:39 imirkin: does it matter? presumably it just has to be higher than the max platform that mesa supports
13:39 haasn: yes, which is exactly the problem
13:39 haasn: it isn't
13:39 imirkin: mesa supports METAL?
13:39 haasn: no, but _HEADLESS (which comes after _DISPLAY)
13:40 imirkin: hehehe ok
13:40 haasn: (_METAL is the highest)
13:40 haasn: *sigh* it still segfaults, even with the enum order fixed, mesa's _max patched, and everything rebuilt thrice
13:40 alyssa: robclark: I'm assuming the answer is "heck no", but I'm wondering if EXT_multisampled_render_to_texture could be inferred from GL3 MSAA in some simple cases via reordering opts (specifcally interested in WebGL)
13:41 haasn: what an annoying regression. all I want to do is run my stupid test framework that worked fine for the past year and a half, not spend 2 hours debugging vulkan ecosystem
13:41 alyssa: robclark: (Failing that, drirc options for firefox/chromium to force it...)
13:41 imirkin: alyssa: you'd have to know that the underlying samples are never access directly in the future
13:41 imirkin: alyssa: i don't think there's a way to guarantee that
13:41 alyssa: imirkin: right..
13:42 imirkin: maybe you can do it with the winsys framebuffer
13:42 imirkin: i don't think you can ever peer into its samples when it's multisampled
13:42 alyssa: it's FBOs I'm worried about
13:43 alyssa: GL(ES)3 multisampling on mobile is *slow*
13:43 imirkin: yea
13:43 alyssa: and that's exactly what webgl does in both FF and chrome
13:43 imirkin: ideally you'd do the resolve on your way out of the tile buffer
13:43 imirkin: but you can't with standard MSAA, which is why that ext exists ;)
13:43 alyssa: right, which I have working via that extension with GLES chromium
13:43 alyssa: but that doesn't do anything for desktop GL chromium which is what our users actually use, or ff which doesn't use the ext
13:43 haasn: imirkin: in any case wsi_common_get_surface_support would definitely have to bounds-check `platform->surface` against that PLATFORM_MAX limit
13:43 imirkin: alyssa: was it ever plumbed through mesa?
13:44 alyssa: yeah, krh did for fd
13:44 ajax: gah, icecream95 left
13:44 haasn: otherwise it segfaults on reading past wsi_device->wsi
13:44 imirkin: alyssa: nice
13:44 haasn: (and dereferencing the resulting value)
13:44 imirkin: haasn: i'm not really familiar with the vulkan stuff... not sure who the WSI experts are around here
13:44 imirkin: when in doubt, jekstrand and bnieuwenhuizen ?
13:44 ajax: oh good, they figured it out
13:54 ajax: daniels: re the msaa thing (supra), the general answer to "why don't my fbconfigs reflect the thing i just changed" is "you need to restart xserver with those changes actually loaded"
13:54 imirkin: oh, i hate that so much
13:55 imirkin: so much time spent debugging that
13:55 daniels: don't know what you mean, I have literally never spent hours furiously debugging code it turns out I wasn't actually running
13:55 imirkin: other fun fact - X hard-codes the location that it loads dri drivers from
13:55 imirkin: so the usual tricks don't help
13:55 ajax: not if you're using xwayland from master! you're welcome.
13:56 ajax: should wire up that egl backend to xfree86 too. i _guess_.
13:58 ajax: not much to be done about the restart-the-server bit though, visuals are a static list built at server init time
13:58 ajax: i _guess_ you could regenerate the fbconfigs dynamically and just strip off GLX_WINDOW_BIT for anything that doesn't have a visual, but that seems super fragile
13:58 ajax: and would push the "where's my msaa" problem to "why do i only get msaa for pixmaps"
14:05 MrCooper: imirkin: per the scrollback, the current Xorg glx module does respect LIBGL_DRIVERS_PATH
14:05 imirkin: MrCooper: oh nice! that's new.
14:05 imirkin: (as of last time i had to deal with this, which was admittedly a fairly long time ago)
14:06 imirkin: i'll try to remember that next time i get to play with the glx server side of things
14:06 imirkin: (which will hopefully be never, but one can never be so lucky...)
14:09 bnieuwenhuizen: haasn: does it work with older mesa? I think we upgraded some of the vulkan headers in mesa to 1.2.148 already
14:12 robclark: alyssa: if gl has that discard-framebuffer it could perhaps be inferred by detecting a sequence of draw(s) -> resolve -> discard-framebuffer.. I think that is what krh wants to do but sounds like a pita.. fwiw seems like firefox wayland is using gles (although don't know if it uses the multisample_render_to_texture thing)
14:14 MrCooper: daniels: https://gitlab.freedesktop.org/GL/mesa/-/pipelines/180518 failed due to "Connection reset by peer" on Collabora LAVA runners
14:15 daniels: yeah, for some reason our primary LAVA server is unhealthy, admins are looking into it atm
14:15 daniels: I'm shortly going to be jumping in a car for a while, but if it's still unhealthy in an hour or whatever, please feel to insta-merge a disable with my A-b
14:15 MrCooper: k, thanks
14:16 imirkin:is picturing a trampoline inside a car...
14:19 lynxeye: TBH trampolin inside a car doesn't sound totally atypical for a graphics guy...
14:21 MrCooper: maybe it's a double decker bus :)
14:22 imirkin: yeah, it was a bit unclear whether daniels was going to be jumping inside of a car, or whether he would be in the car while it was jumping
14:22 imirkin: silly english language
14:28 haasn: bnieuwenhuizen: I don't know, haven't tried bisecting anything yet
14:28 haasn: it used to work in the past but that was also with older vulkan-layers / vulkan-headers
14:41 EdB: 'into a car' would have help you :). But he can also have a trampoline next to the car because he enjoy getting into a car that way...
14:55 alyssa: imirkin: car shaped bouncy castle?
14:55 alyssa: robclark: IIRC invalidate framebuffer stuff is gles only... so that doesn't help for chrome/linux at least
14:56 alyssa: maybe the real answer is to get chrome patched upstream to pick gles for [panfrost|freedreno|...]
14:56 robclark: I guess you could detect other forms of invalidation (like glClear())..
14:57 robclark: the ideal thing in general, I think, would be prefer gles if avail, otherwise fall back to gl
15:00 robclark: maybe this is daniels car? https://www.youtube.com/watch?v=CJsbUFtnENs
15:01 imirkin: ah yeah, that makes the most sense
15:02 alyssa: robclark: oh, I guess why that was at the office..
15:03 robclark: :-P
15:04 daniels: how did you know?!
15:05 alyssa: daniels: I'm more impressed you can type on your phone with that thing.
15:08 imirkin: alyssa: practice makes perfect, presumably?
16:09 tomeu: collabora's lava lab is taking jobs again, after a reboot
16:27 MrCooper: tomeu: now there's a MinIO related issue: https://gitlab.freedesktop.org/daenzer/mesa/-/jobs/3746435
16:58 SolarAquarion: dcbaker: https://pastebin.com/raw/MsC5CbfE
16:59 SolarAquarion: there's some strange conversions and stuff going in format_utils.h
17:11 SolarAquarion: got the bc for osmesa https://u.teknik.io/qpIU4.bc
17:22 anholt: MrCooper: I'm seeing that in my failing freedreno trace jobs, too.
17:23 anholt: tried reverting the "prefix artifacts with device name", no luck
17:30 danvet: mlankhorst, need to ff drm-misc-next-fixes now I think
17:30 danvet: airlied, can you pls apply " [PATCH -next] dma-fence: Make symbol 'dma_fence_lockdep_map' static" right after merging mlankhorst 's latest pull?
17:31 danvet: it's not yet in my inbox somehow, and drm-misc-next-fixes is also not yet ready
17:36 pinchartl: danvet: is there still time to get https://lore.kernel.org/dri-devel/20200718001755.GA5962@pendragon.ideasonboard.com/ merged for v5.9 ?
17:38 danvet: yeah I guess airlied should get around to vacuuming up pending pulls
17:39 danvet: oh lolz, maintainer entry says drm-misc, doesn't come in through drm-misc
17:39 danvet: :-)
17:41 pinchartl: danvet: there's a base branch shared with dmaengine, I'm a bit worried of messing this particular case up when merging through drm-misc ;-)
17:42 danvet: yeah it's all fine
17:42 pinchartl: thanks
17:42 danvet: just couldn't resist
17:42 danvet:bad person sometimes
17:44 alimon: tomeu: i'm trying to access the gitlab-ci docs and looks that was already moved to docs.mesa.org, can you point me to the link?
17:45 alimon: tomeu: i found this one, https://docs.mesa3d.org/ci/index.html, is that all?
17:58 jekstrand: I think this MR ought to win some sort of award for "most applicable lables" :)
17:58 jekstrand: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5966
18:03 jenatali: Oof
18:03 karolherbst: I noiced :D
18:04 karolherbst: jekstrand: add "gallium" for the st/mesa bits :p
18:05 karolherbst: and llvmpipe most likely as well?
18:05 airlied: I guess I'll hold off on vallium until after that merge :-P
18:06 karolherbst: airlied: no need
18:06 karolherbst: lp_bld_nir is touched by that MR
18:06 karolherbst: ohhh
18:06 karolherbst: that's what you meant
18:06 karolherbst: nvm
18:07 jekstrand: I am hoping to get at least the first half-dozen patches merged ASAP. Those are the ones that are going to be hell to rebase.
18:07 karolherbst: the nouveau ones look fine btw
18:07 jekstrand: The rest is also going to be a real pain but possible.
18:07 jekstrand: karolherbst: Feel free to give tags on specific patches. :)
18:07 jekstrand: karolherbst: Also, if you wouldn't mind testing it. Nouveau isn't in CI.
18:07 karolherbst: yeah.. wil give it a shot on turing
18:08 karolherbst: the actual arch where nir matters for nouveau :p
18:08 danvet: oh nouveau is on the nir train now too?
18:08 karolherbst: volta+ yes
18:08 jekstrand: danvet: Just about everyone is on the NIR train these days.
18:08 Sachiel: time to come up with something new then
18:09 karolherbst: :D
18:09 karolherbst: anyway, starting with volta we only do TGSI for internal shaders like the blitter
18:09 karolherbst: everything else is nir only
18:10 danvet: nice, I totally missed that volta+ nir for nouveau happened somehow
18:11 ajax: hmph, nobody ported i915g yet?
18:11 karolherbst: yeah, and the support isn't that bad either
18:11 karolherbst: around 5 CTS fails the last time I checked
18:12 jekstrand: ajax: No nor i915 classic. There was some chatter about it a long time ago though.
18:14 airlied: nir->tgsi should cover i915g fine :-P
18:14 karolherbst: probably :D
18:15 anarsoul: I doubt anyone uses it anyway
18:15 imirkin: danvet: realistically it's turing support... not a lot of volta's running around, but turing is the current "latest" gen for desktop/mobile GPUs (and is post-volta)
18:16 anarsoul: imirkin: out of curiosity, what's the status of turing support in nouveau?
18:16 imirkin: anarsoul: karolherbst has been doing a lot of work ironing out the issues
18:16 imirkin: i believe it's pretty functional at this point - passes almost all of CTS
18:17 anarsoul: I've recently got a laptop with gtx 1650 which is apparently turing
18:17 imirkin: yea
18:17 imirkin: TU116 or whatever
18:17 imirkin: should work.
18:17 anarsoul: but I haven't tried nouveau on it :)
18:17 karolherbst: anarsoul: use mesa-git, should just work (tm)
18:17 imirkin: you'll need mesa from git, and also a recent kernel
18:17 anarsoul: karolherbst: how does it coopearate with integrated video?
18:17 karolherbst: there are some patches left I need to upstream, but nothing badly broken
18:18 karolherbst: anarsoul: DRI_PRIME stuff
18:18 karolherbst: the usual way
18:18 anarsoul: blob way is to use prime-run
18:18 karolherbst: not anymore
18:18 karolherbst: they also support prime offloading now
18:18 karolherbst: just different env vars
18:18 anarsoul: hm
18:19 karolherbst: and with turing you even get runtime suspend/resume
18:19 karolherbst: just need to enable it or something?
18:19 karolherbst: dunno
18:19 anarsoul: with nouveau?
18:19 karolherbst: nvidia as well
18:19 anarsoul: what about reclocking?
18:19 karolherbst: all those helper scripts are not needed anymore with the nvidia driver
18:19 karolherbst: no reclocking
18:19 imirkin: what you don't get are clock speeds that allow the nvidia gpu to beat out the integrated one :)
18:19 karolherbst: on some benchmarks nouveau is still faster though :p
18:20 karolherbst: anyway
18:20 anarsoul: I see
18:20 karolherbst: if you do some testing and find bugs, that would be really helpful!
18:20 karolherbst: just did limited testing myself and mainly focused on the CTS and some benchmarks
18:20 anarsoul: I was more interested in poking mesa driver :)
18:20 imirkin: there are some turing-only features which could be exposed
18:20 jekstrand: Like ray-tracing. :-P
18:21 imirkin: not so much on the 1650
18:21 karolherbst: and the VR stuff :p
18:21 anarsoul: what's the tag for nouveau issues on gitlab?
18:21 karolherbst: nouveau
18:21 jekstrand: Yeah, no ray-tracing on 1650, even with the blob.
18:21 anarsoul: jekstrand: 1650 doesn't have ray tracing
18:21 jekstrand: Which is super-annoying. Because they support it on all the other 1600-series cards. Just not 1650.
18:22 jekstrand: It's not fast if it's not an RTX card, but it works.
18:22 karolherbst: anarsoul: anyway, feel free to toy around and file bugs
18:22 imirkin: but like e.g. NV_compute_shader_derivatives is turing+
18:22 karolherbst: I will probably fix them or you :p
18:22 karolherbst: I have a bunch of fixes already though
18:22 karolherbst: so...
18:22 jekstrand: imirkin: It's also IVB+ :-P
18:22 jekstrand: (NV_compute_shader_derivatives, that is)
18:22 imirkin: jekstrand: yes, that's why it's called NV_foo
18:22 imirkin: :p
18:22 karolherbst: yeah.. not caring about exposing new extensions at this point except the core stuff is already wired up :D maybe later once I am done with the CTS stuff
18:22 imirkin: core is wired up for that ext
18:22 imirkin: i was going to add support for it
18:23 jekstrand: nouvk!
18:23 karolherbst: ahh, cool
18:23 anarsoul: karolherbst: are there any docs on isa?
18:23 imirkin: but then noticed it was turing+
18:23 karolherbst: jekstrand: ahh right, need to talk with skeggsb about it :D
18:23 karolherbst: anarsoul: nothing public
18:23 imirkin: anarsoul: feel free to ask in #nouveau about any specifics
18:23 imirkin: we generally have a reasonable handle on it
18:23 anarsoul: thanks
18:24 imirkin: [and i try not to bore #dri-devel with the details... usually.]
18:24 anarsoul: do I understand correctly that nvidia has to open something (firmware?) in order to enable reclocking?
18:24 imirkin: they have to provide signed firmware which exposes a stable ABI for the kernel-side driver to initiate reclocking
18:25 anarsoul: I see
18:27 anholt: ajax: ntt is my plan for how i915g (and virgl and svga and...) keep going. currently +6% instruction count, more loop unrolling (doesn't count towards that 6%), reduces uniforms count, reduces immediates. temps are a big issue currently, though.
18:28 anholt: (tgsi only has a few bits for register indices, and if you don't do reusing of indices then you lose)
18:31 karolherbst: anholt: emit immediate loads on use instead of when nir tells you
18:31 karolherbst: that reduces temps a lot
18:32 karolherbst: like 40% or so
18:32 anholt: karolherbst: already done
18:32 karolherbst: ahh
18:32 karolherbst: then probably the input stuff is next :p
18:32 karolherbst: nir tends to load them at the start of a block
18:32 anholt: also already done.
18:32 anholt: or, I guess not.
18:33 anholt: but that's not the temps issue, the issue is I'm not register allocating ssa defs or regs or my temps at all
18:33 karolherbst: there is a pass even
18:33 karolherbst: ahh
18:33 karolherbst: I see
18:33 anholt: nir only has a block-level liveness for ssa defs so far
18:33 karolherbst: I need to start caring about optimizing the nir path more :D
18:33 karolherbst: right...
18:34 anholt: oh, and load_input is already handled (you get alu opcodes with input/constant/sysval/immediate file references packed in)
18:35 ajax: losing 6 of your 96 instructions on i915 is... well, screw it, your fault for still being on gen3
18:35 karolherbst: I also meant ubos and wahtever though
18:35 jekstrand: anholt: Do you need more than block-level?
18:35 jekstrand: I guess it depends on how you do RA
18:35 anholt: jekstrand: for a straight line shader, I need to be able to free temps as I go, not at the end of the block
18:35 jekstrand: anholt: Sure, but you can track liveness easily as you walk the shader.
18:35 karolherbst: in case you are looking for ideas for a real RA, skip codegen, it's fundamentally flawed :p
18:36 karolherbst: anholt: is your IR structured or unstructured?
18:36 anholt: tgsi is structured
18:36 karolherbst: I meant whatever you have post TGSI
18:36 jekstrand: anholt: Have an array indexed by SSA def index and, set it to list_length(def->uses) when you see the def and decrement when you see a use.
18:36 jekstrand: Crossing blocks gets a bit more tricky.
18:36 airlied: karolherbst: for i915 and softpipe there is nothing post TGSI
18:36 karolherbst: ehhh
18:36 karolherbst: same as nv30 :/
18:36 jekstrand: But, yeah, we could do some IP-based thing too if that'd be helpful.
18:37 karolherbst: fun projects
18:38 anholt: jekstrand: the ip based thing for ssa defs looked easy given having the control flow liveness sorted out already
18:38 anholt: (then I just need to walk ssa defs and uses per instr to expand on those ranges)
18:39 anholt: the ugly part is regs, but I'm hoping nir ends up being such a win that I don't care.
18:39 jekstrand: anholt: Should be easy enough. Just walk each block backwards.
18:39 jekstrand: Forwards requires reference-counting. Backwards doesn't.
18:39 anholt: for ssa defs?
18:39 jekstrand: Yup
18:40 jekstrand: because you only have one def so, when walking backwards, the moment you see it, it's free.
18:40 anholt: with the separate pass, i don't even need that -- ssa def uses are just interval->end = MAX2(interval->end, instr ip), right?
18:40 anholt: (ureg doesn't have any notion of cursors, so walking backwards sounds hard)
18:40 anholt: walking backwards in codegen, that is
18:40 jekstrand: Yeah, you don't want to walk backwards in codegen. That'd be a pain
18:41 jekstrand: So you either do a more complicated thing to walk forwards and reference count
18:41 jekstrand: Or you do a pre-pass that walks backwards.
18:41 jekstrand: THe pre-pass sounds easier
18:41 jekstrand: And it shouldn't affect compile time significantly.
18:41 anholt: yeah, I'm going for real dumb and simple in the liveness pre pass.
18:42 jekstrand: Or you can index the instructions and then compute the end by max(all uses)
18:42 anholt: I'm curious to see if instr count goes to improvement once I stop doing extra movs for texturing.
18:42 anholt: jekstrand: that was my plan
18:42 jekstrand: The problem is that you still need a second pass
18:43 jekstrand: Because the real question you're asking in codegen is "will this be used again?" so you know whether or not to free it.
18:44 airlied: "90/90 sessions passed, conformance test PASSED
18:44 anholt: with the prepass, I was figuring, after an instruction I do foreach_ssa_use(free temp if my instr's ip matches the end interval), and at the end of the block I free all temps whose end interval matches the block end.
18:44 bnieuwenhuizen: airlied: which one?
18:44 airlied: now to get it into master and CTS fixed
18:44 airlied: bnieuwenhuizen: llvmpipe
18:44 airlied: GL 4.5
18:44 anholt: airlied: nice work
18:44 bnieuwenhuizen: cool :)
18:44 ajax: \o/
18:45 airlied: and if anyone knos anything about compliant line rendering https://gitlab.freedesktop.org/mesa/mesa/-/issues/3292
18:45 jekstrand: anholt: Yeah, that should work.
18:46 jekstrand: anholt: I'm not sure about blocks. I don't think you'll ever have the end of the live interval match block_end.
18:47 jekstrand: It should always end at an instruction
18:47 jekstrand: Well, unless you have phis
18:47 jekstrand: Phi sources occur at block boundaries
18:48 anholt: jekstrand: if my loop uses my outside-defined ssa def on each iteration, and has a conditional break after the use at the top of the loop, it should be in livein/liveout of the block containing the use, right?
18:49 anholt: otherwise iteration 0 gets to overwrite it in the following blocks inside the loop, and iteration 1 gets junk
19:05 EdB: jekstrand: I'm not sure the change on clover worth a label :)
19:23 jekstrand: EdB: It's still a change to clover. :-P
19:31 daniels: anholt: btw, let me know if you want a JWT to play around with MinIO stuff locally and see what's going on
19:34 anholt: daniels: kinda confused, because pipelines are passing, but MrCooper had that same fail on not-freedreno.
19:36 ajax: why is it so difficult to get vim to honor .editorconfig
19:36 anholt: ajax: if it's any consolation, emacs is awful too.
19:36 daniels: anholt: schrödinger's pipelines are passing and also not passing ... ?
19:36 imirkin: we have .emacs files in mesa
19:37 imirkin: or .dir-whatever, i forget the name
19:38 tomeu: alimon: there's still some docs that haven't been moved to pages, but are about to
19:39 anholt: daniels: hmm, is the DurationSeconds=900 in ci_fairy.py meaning the minio credentials will only be good for 15 minutes?
19:39 anholt:would expect lots of intermittent loss in that case
19:41 daniels: I don't know; I've never touched ci-fairy
19:42 alimon: tomeu: so, in which part of the repo can i find that docs?
19:43 tomeu: MrCooper: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6029
19:43 tomeu: alimon: for example:
19:43 tomeu: .gitlab-ci/windows/README.md
19:43 tomeu: .gitlab-ci/tracie/README.md
19:44 alimon: ok
19:45 jenatali: karolherbst (or maybe daniels?): Would love if someone would add appropriate labels for https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6030. Probably nir, spir-v, opencl
19:45 alimon: tomeu: an specific question, where is the definition about which jobs send to which lava server?
19:45 daniels: jenatali: sure, done
19:45 alimon: tomeu: i'm not familiar with gitlab ci yaml files, i will need to review it
19:46 tomeu: alimon: there's a gitlab runner instance per each lava lab
19:47 tomeu: and that gitlab runner has bind-mounted a file with the lava token for the lab it's able to submit to
19:47 tomeu: each gitlab ci job that submits to lava has a runner tag, so the job goes to the right runner
19:48 tomeu: eg. the jobs to that go to baylibre's lab have this tag: mesa-ci-aarch64-lava-baylibre and to collabora's: mesa-ci-aarch64-lava-collabora
19:50 tomeu: alimon: https://docs.mesa3d.org/ci/LAVA.html is up to date
19:50 alimon: tomeu: ok thanks for the pointers, i will read about gitlab runners and the related code
19:50 tomeu: you are welcome!
20:20 jenatali: airlied: If I have patches for your libclc series, what's the right way to share those? Mainly using a hand-rolled mangler rather than the LLVM one, to support the async functions with ocl_event in the mangling, plus address spaces
20:41 airlied: jenatali: just publish a new series, and say based on my work, dont worry about git authorship too much
20:43 jenatali: Cool, that works
21:06 alyssa----:down the framebuffer compression rabbit hole
21:07 SolarAquarion: dcbaker: the compiler backtrace in 368 lines of llvm bitcode
21:08 SolarAquarion: https://gist.github.com/nicolas17/b3fc90d8b135b7148a8070865c1329b8
21:14 dcbaker[m]: SolarAquarion: I have no idea honestly, I just saw lld using lto in your last backtrace and lto can cause weird hard to debug issues like this
21:46 daniels: danvet, airlied: when is the cutoff for misc pull? would be really nice to get the imx8 KMS driver in
21:47 danvet: uh I already pleaded for an extension
21:47 danvet: usually it's -rc6
21:47 danvet: smash it into drm-misc-next, give up shipping product on upstream kernels
21:48 danvet: the extension I pleaded for was for dma-fence and maarten did the pull request for that this morning
21:49 daniels: urgh
21:49 daniels: can you make that extension another day or two? :)
21:49 daniels: NXP vendor BSP makes me cry
21:49 danvet: I kinda don't like that merge window rush thing ...
21:50 danvet: fix upstream release cycle instead :-)
21:50 danvet: or like just ship drm-tip
21:50 daniels: but the kernel development process is perfect
21:50 danvet: perfect for making innocent souls cries
21:50 danvet: indeed perfect
21:51 danvet: also bit late for english over here
21:51 daniels: ah, you should get an extension
21:52 airlied: danvet, daniels : for a new driver I can be a bit more flexible
21:52 airlied: since in theory you can't break anything much
21:52 airlied: but it should be a separate pull maybe for the initial merge if it can't make misc
21:52 danvet: https://lore.kernel.org/intel-gfx/20200715115147.11866-2-chris@chris-wilson.co.uk/ <- airlied bugfix for right after maarten's pull
21:52 danvet: it showed up now
21:53 danvet: daniels, bribe mlankhorst to get that done then
21:53 danvet: (the topic pull)
21:54 daniels: awesome, thanks! I'll make sure that happens then - it can't cause regressions in any case ;)
21:54 danvet: it's too pretty for that I guess
21:55 SolarAquarion: dcbaker[m]: it may be a lld bug, but ld proper has issues
21:55 mareko: what's your opinion on the PIPE_TRANSFER_* -> PIPE_MAP_* renaming?
21:58 daniels: danvet: thing on screen is usually much more pretty than nothing on screen, so yeah, I guess ...
22:22 jenatali: airlied: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6035 - I'm pretty sure that's all the libclc-related changes we're running with, minus a few for hooking up async copies
22:23 jenatali: Though I'm happy to split it if people think it makes sense
22:40 mareko: is there a manual how to add a gitlab pipeline to mesa?
23:36 karolherbst: mhhhh
23:36 karolherbst: can we allow any user to assign labels to bugs?
23:37 karolherbst: or a way of allow predefined labels when creating bugs or something
23:39 jenatali: I'd also love to add labels to MRs while we're asking for features
23:41 airlied: jenatali: you should be able
23:41 airlied: at least I though reporter could do that, butmaybe not
23:41 jenatali: airlied: Nope, only issues
23:41 bnieuwenhuizen: airlied: labels on bugs is "reporter", labels on MR is "developer"
23:41 airlied: ah lols
23:42 bnieuwenhuizen: of course the short term small scale solution is to give jenatali developer access once he has submitted a few :)
23:43 jenatali: There's a few more on my backlog I need to port over, but that still feels like a hurdle for first-time contributors. But I'm also new to GitLab so idk
23:44 bnieuwenhuizen: honestly I feel that if there are new contributors who can't set tags it is for us to worry about them and not the new contributors (though maybe that is making new contributors feel too much like they aren't in control?)
23:45 jenatali:shrugs
23:46 jenatali: I'm already a special case since I've been working on a fork for a while, but still talking to you all, so I probably can't really put myself in a typical new contributor's shoes
23:46 danvet: 1y ago our first contributor process was like "try one of these bazillion tutorials about how to submit a patch to a mailing list, all of which don't really work"
23:47 jenatali: ... I'm glad I waited until gitlab before trying to contribute then :)
23:54 zf: (it worked for me)
23:54 zf: (except that by that point people had stopped paying attention to the mailing list)