00:00 airlied: so you can do what you like
00:00 karolherbst: right and I am not even sure why they even exist
00:00 jenatali: Oh I assumed these were bit ops
00:00 airlied: nope 32bit ptr bool resuly
00:01 airlied: bbiaw dentst
00:01 karolherbst:doesn't get the point of atomic_flag at all...
00:02 karolherbst: that's just like a normal atomic, no?
00:03 airlied: hence why i wanted to lower it :-p
00:04 jenatali:shrugs
00:04 jenatali: Fine by me, I assumed it was an atomic load, flip bit in bitmask, store, just from the name without looking it up. If it's really just a bool, lower it and be done I think
00:04 karolherbst: I mean.. it's not really a cas or is it?
00:04 karolherbst: more like a fetch and set
00:05 karolherbst: although I guess on a bool it doesn't really matter all that much
00:05 karolherbst: either it's false and is true afterwards, or it was already true
00:06 karolherbst: airlied: maybe atomic_exchange?
00:06 karolherbst: that's a normal "get me the value, and set" thing, no?
00:06 karolherbst: but maybe it also doesn't matter
00:07 karolherbst: could probably also use atomic_or
00:07 karolherbst: :D
00:33 airlied: karolherbst: and also I the exst in CL cause C11 has them, at least x86 can do them native I tthnk
00:34 karolherbst: airlied: btw, this entire code block here, could that just be a bitcast to vec4 + shuffle? https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/src/gallium/auxiliary/gallivm/lp_bld_swizzle.c#L500-553
00:35 karolherbst: would just solve the BE issue
00:40 airlied: karolherbst: can't use a vec4 there though
00:41 karolherbst: why not?
00:41 airlied: at leats I don't think you can
00:41 airlied: llvm uses vecs for it's channels
00:41 airlied: but maybe type4 is fine
00:41 airlied: you'd have to see what llvm generates a lot of the uglier code has been to avoid llvm doing something stupid
00:42 karolherbst: mhhh
00:42 HdkR: LLVM generates some hot garbage when you throw non-native size vectors
00:43 karolherbst: my current plan is to fix operation on sizes bigger then the "element size" of pixel data
00:43 karolherbst: airlied: like this: https://gist.github.com/karolherbst/e580bc96bcbeebee6d27e0bdb859de9d
00:44 karolherbst: so if we load bgra8 pixel data as a 32 bit value, we have to fix the load
00:44 karolherbst: because it's now wrong
00:44 karolherbst: when converting to float, this is all fine as the math following the load is all sane
00:44 karolherbst: but in the unorm8 case, we now shift and mask on the 32 bit value again
00:46 karolherbst: messing with the swizzles just end up with a lot of pain because of alpha handling
00:47 karolherbst: or packed format
00:47 karolherbst: and a lot of other stuff
00:47 karolherbst: ohh wait
00:47 karolherbst: actually
00:47 karolherbst: I found the bug...
00:48 karolherbst: wondering what happens if you store a vec4 ...
00:48 karolherbst: I bet llvm turns it into a 32 bit store as well
00:48 karolherbst: *sigh*
01:16 janesma: robclark: I'm getting "fatal error: valgrind.h: No such file or directory"
01:17 janesma:noticed some helgrind commits, will bisect
01:17 robclark: janesma: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3876
01:17 janesma: tks
01:17 robclark: apparently there are some build options that I don't have locally, and aren't covered in CI
01:17 janesma: it happens
01:17 robclark: need to sprinkle more `idep_mesautil` around
01:22 janesma: adding it to three meson files fixes my build
01:23 robclark: yeah, I wish there was an easier way to add a global dependency.. until recently I had no complaints about meson.. now I have one (but that is still fewer than other build system alternatives ;-))
01:23 janesma: are you already fixing this or should I make an MR?
01:24 janesma:finds more examples with our buildtest target
01:24 robclark: pls make an MR if you don't mind (since I'm not sure what the three meson files you fixed are)
01:25 janesma: no problem
01:26 robclark: thx
01:27 robclark: btw, if you have the meson options used for the builds that failed, I'll add them locally
01:44 janesma: I'm currently building with -Dbuild-tests=true -Dgallium-drivers=kmsro,radeonsi,r300,r600,nouveau,freedreno,swrast,v3d,vc4,etnaviv,tegra,svga,virgl,swr,panfrost,iris,lima,zink -Dgallium-vdpau=true -Dgallium-xvmc=true -Dgallium-xa=true -Dgallium-va=true -Dgallium-nine=true -Dgallium-opencl=standalone -Dtools=all -Dgallium-omx=bellagio
01:47 robclark: ok, looks like there have been some new things added since I last updated my regen.sh script
01:50 janesma:not confident he has everything either
01:52 robclark: janesma: oh, I suspect you are right about gitlab CI not building with valgrind enabled.. that would explain things
01:54 janesma: dang there are a lot of meson files to update
01:56 robclark: yeah, it is kinda sad
01:56 robclark: the root problem is mtypes.h pulls in simple_mtx.h
01:57 robclark: so basically dep_valgrind or idep_mesautil needs to be nearly everywhere :-(
01:59 airlied: robclark: why does ir3 need mtypes.h?
02:00 dcbaker[m]: You could add dep_valgrind to idep_mesautils
02:04 janesma: robclark: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7765
02:05 robclark: dcbaker[m]: yes, I did that already.. but that isn't global enough.. I suppose the root issue is components can #include stuff from util without idep_mesautil
02:05 robclark: janesma: thx
02:09 janesma:just checking the build in intel's ci
02:10 janesma: robclark: should I put your rb on it?
02:11 robclark: janesma: maybe a-b?
02:11 robclark: but that should be enough to hand it off to marge
02:12 janesma: yep
03:37 HdkR: What's the current expected release date for 20.3?
03:42 airlied: HdkR: in theory today, not sure how we are going on that in practice
03:43 airlied: HdkR: may be tomorrow for some people)
03:43 airlied: but I epxect dcbaker[m] will do an rc3, soe maybe a week out from now
03:44 HdkR: Sounds good, I was just rebuilding mesa for my rootfs and saw there was an RC. I'll keep it high on my radar to rebuild again
03:44 dcbaker[m]: If the release tracker is clear we can do final tomorrow, but yeah, otherwise probably next week
03:44 dcbaker[m]: I haven't looked at the tracker today
03:44 dcbaker[m]: Though I should
05:13 airlied: hmm might have to disable the coroutines stuff if I don't have any barriers, llvm seems to spend a bit of time at compile time dealing with it
05:33 jekstrand: airlied: What's atomic_flag?
05:43 airlied: jekstrand: two spirv kernel opcodes
05:44 airlied: for C11 atomics
05:44 airlied: atomic_flag_test_and_set and atomic_flag_clear
05:58 jekstrand: airlied: Yeah.... Given that zero thought, I'm afraid.
06:04 airlied: jekstrand: it's cool, I'm just lowering them in vtn for now, if someone really wants them native I'm happy to review it :-P
07:53 tzimmermann: maxime, danvet, can we cherry-pick 8e3784dfef8a ("drm/ast: Reload gamma LUT after changing primary plane's color format") into drm-misc-fixes? it fixes a bug that was reported against upstream
07:55 danvet: tzimmermann, yeah just do that with a reference to the -next commit and short reason why or something like that
07:55 danvet: just so that when -next lands it's less confusing
07:56 tzimmermann: ok
07:57 danvet: maybe we should have that in the dim docs somewhere
07:58 danvet: under "Misplaced commit" or something like that
08:54 MrCooper: hmm, why do some mesa/mesa pipelines like https://gitlab.freedesktop.org/mesa/mesa/-/pipelines/234253 have an external have an external stage for AppVeyor? Is that enabled in the main project settings?
08:55 MrCooper: ugh, pretend I didn't repeat three words there
09:09 pq: emersion, I am right now pondering how I am going to test Weston's YUV shaders. I'd like to have CI test them, but not sure it's in scope for me right now - and I'm in the process of rearranging all the shaders too. :-/
09:11 pq: emersion, lrusak, I'd love to have YUV test data that actually makes sense.
09:14 pq: emersion, lrusak, I have made the mistake of thinking that EGL Wayland platform has native visuals before...
09:16 pq: swick, yeah, there is a little bit of that, but fundamentally I'm looking to make the shared code a *lot* easier to read.
09:18 jadahl: pq: shared code for shaders and what not?
09:19 pq: erg, shader, not shared
09:20 pq: the probability of me typoeing shader as shared is like 70%
09:21 jadahl: heh
09:28 emersion: pq: oh, the EGL wayland platform doesn't have visuals?
09:28 emersion: that's news to me, i've been using WL_SHM_FORMAT_*
09:28 pq: emersion, I think only the GBM platform has pixel formats in the visuals.
09:29 pq: I recall daniels correcting me, when I claimed that of course the Wayland platform has pixel formats in the visuals :-)
09:29 emersion: pq: maybe we should generate reference data with imagemagick or ffmpeg, but i'm not sure it would guarantee the precision is retained. we'd need to carefully choose the test patterns
09:30 emersion: hm
09:34 pq: emersion, I also have a practical problem: to test GL shaders, the YUV data needs to be in dmabufs, at least for multi-planar formats. I wonder how I can create such dmabufs in a client, so it works both in CI (llvmpipe) and with hw drivers.
09:35 pq: would manual allocation with GBM API work?
09:35 pq: fetching the DRM device from wl_drm manually
09:38 emersion: or just picking the first device from drmGetDevices()
09:38 emersion: yeah, i'd just do the buffer creation via GBM
09:41 pq: the first device from drmGetDevices() will likely be wrong for my hw tests
09:43 emersion: right. dmabuf-hints when?
09:53 pq: I hear leandrohrb is looking at it :-)
10:09 uis: What ogl calls can cause syncronization?
10:12 MrCooper: what kind of synchronization?
10:12 daniels: emersion: where have you been 'using' visual formats?
10:14 emersion: daniels: on the wayland platform, i've been checking eglGetConfigAttrib(EGL_NATIVE_VISUAL_ID) is a specific WL_SHM_FORMAT_* member
10:14 uis: IDK. intel-gpu-overlay from igt shows 370ms waits
10:15 daniels: emersion: *blink*
10:15 emersion: https://github.com/swaywm/wlroots/blob/713c1661b742f93a7d2167321837c0d99541ca87/render/egl.c#L32
10:15 emersion: visual_id = WL_SHM_FORMAT_ARGB8888
10:16 emersion: https://github.com/swaywm/wlroots/blob/713c1661b742f93a7d2167321837c0d99541ca87/backend/wayland/backend.c#L304
10:17 emersion: on EGL_PLATFORM_X11_KHR, i've been setting visual_id to screen->root_visual
10:17 emersion: … this sounds broken
10:17 daniels: are you sure that isn't just matching because WL_SHM_FORMAT_ARGB8888 is 0 ... ?
10:18 daniels: because we never fill in NATIVE_VISUAL_ID anywhere
10:18 emersion: lol
10:18 emersion: that's certainly possible
10:19 emersion: you do set it for the GBM platform though, right?
10:20 daniels: oh yeah, you also don't check if it matches when visual_id is 0 :P
10:20 emersion: maybe screen->root_visual ends up being 0 too
10:20 emersion: yeah
10:20 daniels: yes, GBM sets it to a GBM_FORMAT_* enum, and _not_ the 0/1 GBM_BO_FORMAT_[XA]RGB8888 enums
10:20 daniels: X11 will also set it
10:20 emersion: ok
10:20 emersion: ah, all right
10:21 emersion: so only wayland is broken then, and works "by chance"
10:21 emersion: any reason why you don't set it?
10:22 emersion: describing the format you want with egl config is… hm… not great
10:22 emersion: i'd much rather explicitly say "i want XRGB8888 in particular"
10:23 daniels: EGL configs aren't great, but we'd have to then make wl_drm mandatory
10:23 daniels: which I'd be entirely OK with at this point
10:23 daniels: well, not wl_drm, but some kind of registry of fourcc values
10:23 daniels: and hope that fbsd never picks different ones
10:25 emersion: drm_fourcc.h?
10:25 emersion: does that imply we need to amend the EGL spec?
10:26 daniels: what of it?
10:28 emersion: EGL_EXT_platform_wayland
10:28 emersion: state the visuals are drm_fourcc.h codes?
10:29 emersion: e.g. the GBM platform spec states:
10:29 emersion: > For each EGLConfig that belongs to the GBM platform, the EGL_NATIVE_VISUAL_ID attribute is a GBM color format
10:30 emersion: i guess that would make the current mesa impl non-conformant…
10:38 daniels: well, you could state that it could be a DRM FourCC or nothing
10:38 daniels: *or zero
10:40 pq: so lucky that zero is not a valid DRM fourcc, unlike in wl_shm formats
10:49 daniels: quite
11:39 pendingchaos: jekstrand: are the ANV BVH building kernels public somewhere?
11:40 pendingchaos: we don't know much about our BVH format yet, but I'm curious how usable the kernels might be for us
12:48 uis: Is possible to get and call context-dependent functions?
13:16 emersion: patch for native EGL visuals for wayland https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7772
13:36 kusma: I keep getting what appears to be crashes in the amdgpu driver when running piglit quick_gl. I notice this is similar to what happens here, but I'm using Zink on top of RADV...: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3153
13:39 kusma: When I say it's similar, I really refer to the segfault in ppgtt_memory_al. But things goes much worse after that, first hanging piglit, then eventually freezing the UI, and then usually in the end freezing the whole system (no more ssh etc)
13:45 MrCooper: kusma: sounds like a GPU hang; might be worth running with validation layers enabled
13:46 MrCooper: I've also hit GPU hangs every time I've tried running piglit on zink on radeonsi (only a few times so far, a while ago now)
13:46 kusma: MrCooper: For a full piglit run, that's going to take ages, but I'll give it a try. But besides, I'm not supposed to be able to hang other processes anyway, so this does sound like a kernel problem to me...
13:47 MrCooper: yeah, everyone believes in that utopia at first :) reality is a bit more complicated unfortunately
13:48 MrCooper: we're slowly moving in that direction, but it's not going to happen overnight
13:48 kusma: MrCooper: My exact argument against WebGL / WebGPU ;)
13:49 kusma: Anything I can do to help moving in the right direction? I have dmesg logs :P
13:53 MrCooper: if amdgpu fails to cleanly reset the GPU, might be worth filing an issue for that; beyond that, I suspect your time is better spent hunting for zink / radv bugs which trigger the GPU hang in the first place
13:55 kusma: MrCooper: I will of course try to find out if Zink/RADV does something wrong, but I'd like to also follow up on the kernel side. Where do I report bugs like that?
13:55 kusma: (I'm not a kernel-person, sorry for the ignorance)
13:56 MrCooper: https://gitlab.freedesktop.org/drm/amd
13:56 kusma: Thanks!
14:51 jekstrand: pendingchaos: Not yet.
14:52 jekstrand: pendingchaos: They'd probably be usable for you with modification.
14:52 jekstrand: pendingchaos: Trying to get GPU BVH building sorted and upstream is going to be my first major task in 2021
14:53 jekstrand: pendingchaos: To get off the ground, the Embree solution works well.
14:55 jekstrand: pendingchaos: Also, before you can think about using the BVH building kernels from Intel, you'll probably want to spend some time on radeonsi clover via the NIR path.
15:32 uis: Can Mesa cancel drawcalls between glClear and last buffers swap? Or something like this. E.g. frame 0 is rendering, frame 1 in queue and now glxswap for frame 2. Can Mesa just skip drawcalls from frame 1? If not why and can be it implemented?
15:39 uis: I think it will be useful when gpu is bottleneck by avoiding syncronization and skipping outdated frame
15:41 HdkR: Since mesa isn't an emulator, that's a bad idea
15:42 HdkR: You'll likely get frames doing a ton of work, and then you've thrown away, say a compute job doing important work that can't be skipped
15:44 ajax: there's not really a way in GLX to issue a cancellable swap
15:57 uis: ajax: Cacnel not only swap, but gl*Draw* too
16:00 MrCooper: could be tricky to prove that there are no side effects from what you'd like to drop
16:01 MrCooper: also, frame 1 might still make it for the next display refresh cycle, whereas frame 2 might not
16:02 MrCooper: in short, not as simple as you'd like I'm afraid
16:07 HdkR: In a world of TAA, the previous frames always matter
16:18 danvet: airlied, btw for the nouveau regression I caused, should I put it into drm-misc-fixes or bskeggs pull?
16:18 danvet: if it's not in the nouveau pull you need to apply it I guess
16:19 MrCooper: lynxeye: you're saying etnaviv has solved the halting problem? ;)
16:41 danvet: daniels, you mean we should limit the pages job to the master branch or something?
16:41 daniels: danvet: right, if you have multiple branches
16:41 danvet: MrCooper, you don't have that?
16:41 daniels: else you have overlapping deploys
16:42 danvet: I guess I can ignore that one for now
16:42 MrCooper: I don't have what?
16:42 danvet: MrCooper, a halting problem solver in your hangcheck
16:42 MrCooper: Mesa does limit the pages job to the mesa/mesa master branch FWIW
16:43 danvet: in the kernel it'd be nice to review doc patches
16:43 danvet: if we could build pull requests somewhere at least
16:43 MrCooper: danvet: (ignoring it's not my driver anymore ;) not that I know of, and I can't see how it's possible in general given the halting problem
16:43 danvet: MrCooper, a very late joke, and a bad one, it was
16:44 MrCooper: danvet: Mesa has a separate job for that, which does mostly the same things as pages (to make sure the docs build works) but doesn't actually deploy
16:44 MrCooper: danvet: ah, heh
16:44 danvet: yeah but something that's served over html directly is nice
16:44 MrCooper: sorry for being dense
16:44 danvet: maybe need to look into the gilab continuous deploy stuff perhaps
16:44 danvet: eventually
16:44 danvet: but yeah for kernel probably want a docs build job anyway
16:45 MrCooper: danvet: something like https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/318 then?
16:49 danvet: MrCooper, oh nice (if it would work I guess)
16:50 MrCooper: it works with a few extra clicks
16:51 MrCooper: hmm or maybe not
16:52 danvet: agd5f, hm should vga_client_register should that complain if the passed pdev doesn't have the vga bits set?
16:52 MrCooper: I thought it worked before, but now I could only seem to download e.g. index.html
16:56 agd5f: danvet, maybe? I don't remember what the underlying problem was on asics without VGA support
16:56 danvet: most callers currently don't check the error, so something in there might be useful
16:57 danvet: anyway was just an idea
16:57 agd5f: I can double check with the team that was working on it
16:57 danvet: vgaarb freaks me out :-)
16:57 danvet: yeah might be good, if there's anything we could bake as a learning into vgaarb.c
17:01 agd5f: I suspect it's to avoid vga arb (via driver callback) twiddling registers that don't exist on some chips, but I'll confirm
17:01 danvet: from a quick look I thought vgaarb should filter these out
17:01 danvet: but maybe it doesn't, so perhaps needs more checking
17:31 uis: Ok. Is any cancelable drawcall extension exists?
17:44 airlied: danvet: probably misc is more expedient ifI get misc-fixes again
17:48 airlied: kusma: not crashing others is a bit of a strech goal for amdgpu most days, I think they are good on the infintte looping shader, but most other things are pretty random on if you make it out
17:57 karolherbst: soo... first proper BE MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7776
18:07 mattst88: nice. I'm looking forward to seeing those tests fixed :)
18:53 dcbaker[m]: Anyone got any idea why appveyor is suddenly failing on 20.3 in pipe-loader.c? It doesn't look like it's been touched? https://ci.appveyor.com/project/mesa3d/mesa-ftwhm/builds/36511344
18:54 airlied: maybe it wasn't built on Windows before?
19:07 karolherbst: mattst88: u_format_test is already passing locally :) but before I also fix the llvmpipe ones I kind of want to make sure that the test data is correct on its own.. and I still need to figure out if the test itself is not broken
19:15 jenatali: dcbaker[m]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7680/diffs?commit_id=8e5af18450c2b0bb55e6d196ca5f68893f48a696
19:16 jenatali: That commit fixes that error
19:16 jenatali: Though apparently it also breaks Linux builds according to CI, I haven't gotten a chance to dig in and see why yet
19:17 dcbaker[m]: jenatali: I wondered if you knew what was going on :)
19:17 jenatali: dcbaker[m]: Yeah, pipe-loader isn't normally needed for just GL, but trying to add in Clover pulls it in
19:18 jenatali: Not sure why your appveyor build is pulling it in now though, unless you've got a new option being set somewhere?
19:52 airlied: dcbaker[m]: ah jose said appveyor was broken
19:53 dcbaker[m]: I'm just going to turn it off on 20.3 then, and if it gets fixed we can re-enable it
20:39 airlied: Lyude: https://patchwork.freedesktop.org/series/81702/ is the latest version of dpcd backlight?
20:48 Lyude: airlied: yeah
20:49 Lyude: i can rebase and such if needed
20:51 airlied: Lyude: couple of checkpatch warnings in there might be worth a cleanup
20:51 Lyude: airlied: sure thing - were you planning on doing a refer btw? or did someone else ask about it
20:54 airlied: I was going look at reviewing it today
20:54 Lyude: airlied: alright I can go ahead and do the cleanup now if you want, or just wait for your review
20:56 airlied: Lyude: I'll review and then maybe you can remove rfc and checkpatch
21:15 uis: https://github.com/uis246/OpenGL-Registry/blob/master/extensions/EXT/EXT_discardable_calls.txt
21:15 uis: Just idea