00:00airlied: so you can do what you like
00:00karolherbst: right and I am not even sure why they even exist
00:00jenatali: Oh I assumed these were bit ops
00:00airlied: nope 32bit ptr bool resuly
00:01airlied: bbiaw dentst
00:01karolherbst:doesn't get the point of atomic_flag at all...
00:02karolherbst: that's just like a normal atomic, no?
00:03airlied: hence why i wanted to lower it :-p
00:04jenatali: 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:04karolherbst: I mean.. it's not really a cas or is it?
00:04karolherbst: more like a fetch and set
00:05karolherbst: although I guess on a bool it doesn't really matter all that much
00:05karolherbst: either it's false and is true afterwards, or it was already true
00:06karolherbst: airlied: maybe atomic_exchange?
00:06karolherbst: that's a normal "get me the value, and set" thing, no?
00:06karolherbst: but maybe it also doesn't matter
00:07karolherbst: could probably also use atomic_or
00:33airlied: karolherbst: and also I the exst in CL cause C11 has them, at least x86 can do them native I tthnk
00:34karolherbst: 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:35karolherbst: would just solve the BE issue
00:40airlied: karolherbst: can't use a vec4 there though
00:41karolherbst: why not?
00:41airlied: at leats I don't think you can
00:41airlied: llvm uses vecs for it's channels
00:41airlied: but maybe type4 is fine
00:41airlied: you'd have to see what llvm generates a lot of the uglier code has been to avoid llvm doing something stupid
00:42HdkR: LLVM generates some hot garbage when you throw non-native size vectors
00:43karolherbst: my current plan is to fix operation on sizes bigger then the "element size" of pixel data
00:43karolherbst: airlied: like this: https://gist.github.com/karolherbst/e580bc96bcbeebee6d27e0bdb859de9d
00:44karolherbst: so if we load bgra8 pixel data as a 32 bit value, we have to fix the load
00:44karolherbst: because it's now wrong
00:44karolherbst: when converting to float, this is all fine as the math following the load is all sane
00:44karolherbst: but in the unorm8 case, we now shift and mask on the 32 bit value again
00:46karolherbst: messing with the swizzles just end up with a lot of pain because of alpha handling
00:47karolherbst: or packed format
00:47karolherbst: and a lot of other stuff
00:47karolherbst: ohh wait
00:47karolherbst: I found the bug...
00:48karolherbst: wondering what happens if you store a vec4 ...
00:48karolherbst: I bet llvm turns it into a 32 bit store as well
01:16janesma: robclark: I'm getting "fatal error: valgrind.h: No such file or directory"
01:17janesma:noticed some helgrind commits, will bisect
01:17robclark: janesma: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3876
01:17robclark: apparently there are some build options that I don't have locally, and aren't covered in CI
01:17janesma: it happens
01:17robclark: need to sprinkle more `idep_mesautil` around
01:22janesma: adding it to three meson files fixes my build
01:23robclark: 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:23janesma: are you already fixing this or should I make an MR?
01:24janesma:finds more examples with our buildtest target
01:24robclark: pls make an MR if you don't mind (since I'm not sure what the three meson files you fixed are)
01:25janesma: no problem
01:27robclark: btw, if you have the meson options used for the builds that failed, I'll add them locally
01:44janesma: 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:47robclark: ok, looks like there have been some new things added since I last updated my regen.sh script
01:50janesma:not confident he has everything either
01:52robclark: janesma: oh, I suspect you are right about gitlab CI not building with valgrind enabled.. that would explain things
01:54janesma: dang there are a lot of meson files to update
01:56robclark: yeah, it is kinda sad
01:56robclark: the root problem is mtypes.h pulls in simple_mtx.h
01:57robclark: so basically dep_valgrind or idep_mesautil needs to be nearly everywhere :-(
01:59airlied: robclark: why does ir3 need mtypes.h?
02:00dcbaker[m]: You could add dep_valgrind to idep_mesautils
02:04janesma: robclark: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7765
02:05robclark: 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:05robclark: janesma: thx
02:09janesma:just checking the build in intel's ci
02:10janesma: robclark: should I put your rb on it?
02:11robclark: janesma: maybe a-b?
02:11robclark: but that should be enough to hand it off to marge
03:37HdkR: What's the current expected release date for 20.3?
03:42airlied: HdkR: in theory today, not sure how we are going on that in practice
03:43airlied: HdkR: may be tomorrow for some people)
03:43airlied: but I epxect dcbaker[m] will do an rc3, soe maybe a week out from now
03:44HdkR: 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:44dcbaker[m]: If the release tracker is clear we can do final tomorrow, but yeah, otherwise probably next week
03:44dcbaker[m]: I haven't looked at the tracker today
03:44dcbaker[m]: Though I should
05:13airlied: 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:33jekstrand: airlied: What's atomic_flag?
05:43airlied: jekstrand: two spirv kernel opcodes
05:44airlied: for C11 atomics
05:44airlied: atomic_flag_test_and_set and atomic_flag_clear
05:58jekstrand: airlied: Yeah.... Given that zero thought, I'm afraid.
06:04airlied: 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:53tzimmermann: 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:55danvet: tzimmermann, yeah just do that with a reference to the -next commit and short reason why or something like that
07:55danvet: just so that when -next lands it's less confusing
07:57danvet: maybe we should have that in the dim docs somewhere
07:58danvet: under "Misplaced commit" or something like that
08:54MrCooper: 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:55MrCooper: ugh, pretend I didn't repeat three words there
09:09pq: 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:11pq: emersion, lrusak, I'd love to have YUV test data that actually makes sense.
09:14pq: emersion, lrusak, I have made the mistake of thinking that EGL Wayland platform has native visuals before...
09:16pq: 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:18jadahl: pq: shared code for shaders and what not?
09:19pq: erg, shader, not shared
09:20pq: the probability of me typoeing shader as shared is like 70%
09:28emersion: pq: oh, the EGL wayland platform doesn't have visuals?
09:28emersion: that's news to me, i've been using WL_SHM_FORMAT_*
09:28pq: emersion, I think only the GBM platform has pixel formats in the visuals.
09:29pq: I recall daniels correcting me, when I claimed that of course the Wayland platform has pixel formats in the visuals :-)
09:29emersion: 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:34pq: 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:35pq: would manual allocation with GBM API work?
09:35pq: fetching the DRM device from wl_drm manually
09:38emersion: or just picking the first device from drmGetDevices()
09:38emersion: yeah, i'd just do the buffer creation via GBM
09:41pq: the first device from drmGetDevices() will likely be wrong for my hw tests
09:43emersion: right. dmabuf-hints when?
09:53pq: I hear leandrohrb is looking at it :-)
10:09uis: What ogl calls can cause syncronization?
10:12MrCooper: what kind of synchronization?
10:12daniels: emersion: where have you been 'using' visual formats?
10:14emersion: daniels: on the wayland platform, i've been checking eglGetConfigAttrib(EGL_NATIVE_VISUAL_ID) is a specific WL_SHM_FORMAT_* member
10:14uis: IDK. intel-gpu-overlay from igt shows 370ms waits
10:15daniels: emersion: *blink*
10:15emersion: visual_id = WL_SHM_FORMAT_ARGB8888
10:17emersion: on EGL_PLATFORM_X11_KHR, i've been setting visual_id to screen->root_visual
10:17emersion: … this sounds broken
10:17daniels: are you sure that isn't just matching because WL_SHM_FORMAT_ARGB8888 is 0 ... ?
10:18daniels: because we never fill in NATIVE_VISUAL_ID anywhere
10:18emersion: that's certainly possible
10:19emersion: you do set it for the GBM platform though, right?
10:20daniels: oh yeah, you also don't check if it matches when visual_id is 0 :P
10:20emersion: maybe screen->root_visual ends up being 0 too
10:20daniels: yes, GBM sets it to a GBM_FORMAT_* enum, and _not_ the 0/1 GBM_BO_FORMAT_[XA]RGB8888 enums
10:20daniels: X11 will also set it
10:20emersion: ah, all right
10:21emersion: so only wayland is broken then, and works "by chance"
10:21emersion: any reason why you don't set it?
10:22emersion: describing the format you want with egl config is… hm… not great
10:22emersion: i'd much rather explicitly say "i want XRGB8888 in particular"
10:23daniels: EGL configs aren't great, but we'd have to then make wl_drm mandatory
10:23daniels: which I'd be entirely OK with at this point
10:23daniels: well, not wl_drm, but some kind of registry of fourcc values
10:23daniels: and hope that fbsd never picks different ones
10:25emersion: does that imply we need to amend the EGL spec?
10:26daniels: what of it?
10:28emersion: state the visuals are drm_fourcc.h codes?
10:29emersion: e.g. the GBM platform spec states:
10:29emersion: > For each EGLConfig that belongs to the GBM platform, the EGL_NATIVE_VISUAL_ID attribute is a GBM color format
10:30emersion: i guess that would make the current mesa impl non-conformant…
10:38daniels: well, you could state that it could be a DRM FourCC or nothing
10:38daniels: *or zero
10:40pq: so lucky that zero is not a valid DRM fourcc, unlike in wl_shm formats
11:39pendingchaos: jekstrand: are the ANV BVH building kernels public somewhere?
11:40pendingchaos: we don't know much about our BVH format yet, but I'm curious how usable the kernels might be for us
12:48uis: Is possible to get and call context-dependent functions?
13:16emersion: patch for native EGL visuals for wayland https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7772
13:36kusma: 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:39kusma: 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:45MrCooper: kusma: sounds like a GPU hang; might be worth running with validation layers enabled
13:46MrCooper: 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:46kusma: 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:47MrCooper: yeah, everyone believes in that utopia at first :) reality is a bit more complicated unfortunately
13:48MrCooper: we're slowly moving in that direction, but it's not going to happen overnight
13:48kusma: MrCooper: My exact argument against WebGL / WebGPU ;)
13:49kusma: Anything I can do to help moving in the right direction? I have dmesg logs :P
13:53MrCooper: 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:55kusma: 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:55kusma: (I'm not a kernel-person, sorry for the ignorance)
14:51jekstrand: pendingchaos: Not yet.
14:52jekstrand: pendingchaos: They'd probably be usable for you with modification.
14:52jekstrand: pendingchaos: Trying to get GPU BVH building sorted and upstream is going to be my first major task in 2021
14:53jekstrand: pendingchaos: To get off the ground, the Embree solution works well.
14:55jekstrand: 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:32uis: 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:39uis: I think it will be useful when gpu is bottleneck by avoiding syncronization and skipping outdated frame
15:41HdkR: Since mesa isn't an emulator, that's a bad idea
15:42HdkR: 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:44ajax: there's not really a way in GLX to issue a cancellable swap
15:57uis: ajax: Cacnel not only swap, but gl*Draw* too
16:00MrCooper: could be tricky to prove that there are no side effects from what you'd like to drop
16:01MrCooper: also, frame 1 might still make it for the next display refresh cycle, whereas frame 2 might not
16:02MrCooper: in short, not as simple as you'd like I'm afraid
16:07HdkR: In a world of TAA, the previous frames always matter
16:18danvet: airlied, btw for the nouveau regression I caused, should I put it into drm-misc-fixes or bskeggs pull?
16:18danvet: if it's not in the nouveau pull you need to apply it I guess
16:19MrCooper: lynxeye: you're saying etnaviv has solved the halting problem? ;)
16:41danvet: daniels, you mean we should limit the pages job to the master branch or something?
16:41daniels: danvet: right, if you have multiple branches
16:41danvet: MrCooper, you don't have that?
16:41daniels: else you have overlapping deploys
16:42danvet: I guess I can ignore that one for now
16:42MrCooper: I don't have what?
16:42danvet: MrCooper, a halting problem solver in your hangcheck
16:42MrCooper: Mesa does limit the pages job to the mesa/mesa master branch FWIW
16:43danvet: in the kernel it'd be nice to review doc patches
16:43danvet: if we could build pull requests somewhere at least
16:43MrCooper: 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:43danvet: MrCooper, a very late joke, and a bad one, it was
16:44MrCooper: 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:44MrCooper: danvet: ah, heh
16:44danvet: yeah but something that's served over html directly is nice
16:44MrCooper: sorry for being dense
16:44danvet: maybe need to look into the gilab continuous deploy stuff perhaps
16:44danvet: but yeah for kernel probably want a docs build job anyway
16:45MrCooper: danvet: something like https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/318 then?
16:49danvet: MrCooper, oh nice (if it would work I guess)
16:50MrCooper: it works with a few extra clicks
16:51MrCooper: hmm or maybe not
16:52danvet: agd5f, hm should vga_client_register should that complain if the passed pdev doesn't have the vga bits set?
16:52MrCooper: I thought it worked before, but now I could only seem to download e.g. index.html
16:56agd5f: danvet, maybe? I don't remember what the underlying problem was on asics without VGA support
16:56danvet: most callers currently don't check the error, so something in there might be useful
16:57danvet: anyway was just an idea
16:57agd5f: I can double check with the team that was working on it
16:57danvet: vgaarb freaks me out :-)
16:57danvet: yeah might be good, if there's anything we could bake as a learning into vgaarb.c
17:01agd5f: 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:01danvet: from a quick look I thought vgaarb should filter these out
17:01danvet: but maybe it doesn't, so perhaps needs more checking
17:31uis: Ok. Is any cancelable drawcall extension exists?
17:44airlied: danvet: probably misc is more expedient ifI get misc-fixes again
17:48airlied: 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:57karolherbst: soo... first proper BE MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7776
18:07mattst88: nice. I'm looking forward to seeing those tests fixed :)
18:53dcbaker[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:54airlied: maybe it wasn't built on Windows before?
19:07karolherbst: 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:15jenatali: dcbaker[m]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7680/diffs?commit_id=8e5af18450c2b0bb55e6d196ca5f68893f48a696
19:16jenatali: That commit fixes that error
19:16jenatali: Though apparently it also breaks Linux builds according to CI, I haven't gotten a chance to dig in and see why yet
19:17dcbaker[m]: jenatali: I wondered if you knew what was going on :)
19:17jenatali: dcbaker[m]: Yeah, pipe-loader isn't normally needed for just GL, but trying to add in Clover pulls it in
19:18jenatali: Not sure why your appveyor build is pulling it in now though, unless you've got a new option being set somewhere?
19:52airlied: dcbaker[m]: ah jose said appveyor was broken
19:53dcbaker[m]: I'm just going to turn it off on 20.3 then, and if it gets fixed we can re-enable it
20:39airlied: Lyude: https://patchwork.freedesktop.org/series/81702/ is the latest version of dpcd backlight?
20:48Lyude: airlied: yeah
20:49Lyude: i can rebase and such if needed
20:51airlied: Lyude: couple of checkpatch warnings in there might be worth a cleanup
20:51Lyude: airlied: sure thing - were you planning on doing a refer btw? or did someone else ask about it
20:54airlied: I was going look at reviewing it today
20:54Lyude: airlied: alright I can go ahead and do the cleanup now if you want, or just wait for your review
20:56airlied: Lyude: I'll review and then maybe you can remove rfc and checkpatch
21:15uis: Just idea