04:19kode54: oops
04:20kode54: people once again using %lu for uint64_t
04:20kode54: (and thank you, again, compiler gods, for requiring the world to use things like PRIu64 to be architecture compatible)
04:24HdkR: Time to use c++20 formatting tools. Just use {} for everything :D
04:25kode54: probably not too many people testing their code with a build setup that produces a full multilib build
04:25kode54: though CI would definitely catch that
04:32DavidHeidelberg: anyone from AMD would be willing to look why raven2 is hanging a lot on our CI with 6.5 (6.4 we use now is just fine)? https://gitlab.freedesktop.org/mesa/mesa/-/issues/9865
04:41mareko: agd5f: ^^
06:22javierm: tzimmermann: I was on holidays yesterday, I'll take a look to the patch-set today
06:37soreau: daniels: When I force push my branch to update i.e. https://gitlab.freedesktop.org/mesa/kmscube/-/merge_requests/47 it sends a ci-fail message to my inbox because I lack permissions to run it. Is there anything that can be done so it runs the ci successfully when I force push?
06:40soreau: robclark: eric_engestrom: who should I ping about this MR to have it reviewed? ^^
06:50tzimmermann: javierm, thank you
09:10soreau: zmike: got xwayland working with zink and no modifiers using a hacky 3 liner patch (see the issue)
09:14kode54: soreau: you are cool
09:20soreau: kode54: well, not yet.. that was only in nested wayland backend
09:20kode54: Oh
09:21kode54: Well, get it to where you can dogfood it
09:21kode54: I’m maining your track-wlroots branch at least
10:27MrCooper: can commit_tail get called from atomic context?
10:42MrCooper: err, make that drm_atomic_helper_commit with nonblock=false
11:58karolherbst: alyssa, gfxstrand: any comments/complains on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25330/diffs?commit_id=b5e51b631cc1097385768f7fabafb1002820fe0d ? Kinda want to land it so vec4 backends can start using it for vec8/16 lowering
11:58karolherbst: unless you have better ideas or other suggestions
12:05tzimmermann: arnd, hi. what happened to https://lore.kernel.org/dri-devel/20230719123944.3438363-2-arnd@kernel.org/ did you merge this patchset?
12:08daniels: soreau: https://gitlab.freedesktop.org/freedesktop/freedesktop/-/wikis/home
12:14alyssa: karolherbst: no comments or complaints
12:15karolherbst: ehh wait
12:15karolherbst: I linked the wrong commit
12:15karolherbst: alyssa, gfxstrand: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25330/diffs?commit_id=0d5b2d8f5bd69a40d2cc5392fe9500a0518cbba0
12:21arnd: tzimmermann: I actually wanted to get back to this today, and something else came up. I had been travelling most of the time in the last six weeks, so I did not get to it earlier
13:03karolherbst: zmike: question.. if I call launch_grid, then memory_barrier(PIPE_BARRIER_ALL) then resource_map a buffer used in launch_grid, should I expect the content behind the map pointer to be synced?
13:05karolherbst: maybe some zink_batch_reference_resource_rw are missing for the global buffers..
13:10karolherbst: ehh
13:10karolherbst: buffer_map I mean
13:15zmike: karolherbst: no
13:16zmike: you'd need to map the buffer persistently
13:18karolherbst: mhhh.... kinda annoying, because it's not necessarily a buffer not being created with PIPE_RESOURCE_FLAG_MAP_PERSISTENT
13:18karolherbst: s/not/
13:19karolherbst: also, I just wnat to copy the buffers content to host memory
13:20zmike: then you could also manually sync it
13:20karolherbst: yeah, that would be fine
13:20zmike: I think that's a transfer_map_flush thing but I'll have to get down to my office and check
13:21zmike: alternatively resource_copy_region ?
13:22karolherbst: that only works between two resources.. but I guess I could create a temporary one
13:22karolherbst: but that kinda sounds a bit wasteful to do
13:23karolherbst: right.. there is transfer_flush_region
13:23karolherbst: yeah, let me look into that
13:26karolherbst: ehh.. looks like that's only for writes into the mapped area
13:41tzimmermann: arnd, ah ok. what a coincidence
13:50zmike: karolherbst: I'm not sure there's a gallium api for this
13:50karolherbst: yeah.. me neither
13:51zmike: I'd suggest using a persistent+coherent staging resource
13:51karolherbst: mhhh
13:51zmike: zink does slab allocation anyway so it's basically free if you tack it on to the end of your cmdbuf right before a flush
13:52karolherbst: I think I'd rather change the gallium API, because zink is the only driver where it doesn't work
13:52zmike: what are you doing for other drivers that makes it work?
13:52karolherbst: nothing
13:53zmike: 🤔
13:53karolherbst: other drivers seem to synchronize things, or rather.. do things in a way, that I can use buffer_map in my use case
13:53karolherbst: I didn't check though
13:54zmike: maybe describe your case a bit better
13:54karolherbst: I just want to map a buffer after launch_grid and see the writes to it from that compute shader
13:55zmike: that should work?
13:55karolherbst: I think that's unknown, all I can say is that I don't have that issue with other drivers
13:55zmike: give me a branch and a test case
13:56karolherbst: my rusticl/zink branch + test_conformance/basic/test_basic if
13:56karolherbst: have to set "CL_DEVICE_TYPE=CL_DEVICE_TYPE_GPU RUSTICL_ENABLE=zink"
13:59karolherbst: zmike: mhhh...
13:59karolherbst: there might be a different fix for me
13:59karolherbst: atm I flush/finish the context after doing the map + copy.. maybe I should flush first, then copy the buffer..
13:59karolherbst: that seems to fix it for zink at least
14:00karolherbst: there is a "blocking_read/blocking_write" argument to some of the CL operations and I should probably finish the context before doing those operations...
14:00karolherbst: let me toy around with that first
14:01zmike: map should automatically be doing the sync as long as you aren't trying to map it asynchronously
14:01karolherbst: yeah... that's what I assumed
14:02karolherbst: but `zink_buffer_map` doesn't seem to sync anything before `zink_copy_buffer`
14:04zmike: hmmm
14:04zmike: what is this buffer used for?
14:04zmike: ssbo?
14:04karolherbst: yeah, CL global memory
14:04zmike: you need a memory barrier between launch_grid and copy
14:05karolherbst: I tried to add calls to zink_batch_reference_resource_rw for each buffer inside ctx->di.global_bindings but that didn't seem to help
14:05karolherbst: yeah..
14:05karolherbst: I have one :)
14:05karolherbst: though currently I'm using PIPE_BARRIER_GLOBAL_BUFFER
14:05karolherbst: but BARRIER_ALL also didn't help
14:05karolherbst: but maybe zink has to add some barrier handling for global_bindings
14:06zmike: I'll look in a few, gotta actually afk a bit now
14:06karolherbst: yeah, no worries, I'll dig into it a bit
14:11mareko: karolherbst: any reason for the si_clear_render_target change here? https://gitlab.freedesktop.org/-/snippets/7690
14:11karolherbst: I didn't try without it
14:11karolherbst: but it's probably fine without it, let me do a run without it
14:17karolherbst: zmike: doing "zink_screen(ctx->base.screen)->buffer_barrier(ctx, src, VK_ACCESS_FLAG_BITS_MAX_ENUM, 0);" instead of VK_ACCESS_TRANSFER_READ_BIT seems to fix it...
14:17zmike: literally what are you doing
14:18karolherbst: launch_grid, memory_barrier + buffer_map
14:19karolherbst: maybe something bda specific needs to be done here or something...
14:19zmike: still struggling to build cts again
14:19karolherbst: yeah.. it's a pain, probably fails due to outdated CL headers
14:20karolherbst: just use an older commit
14:20karolherbst: on fc38 588a935e9d90c92839f3d256d82c35d3f081075a should work
14:20karolherbst: uhm..
14:20karolherbst: 0702f2ecee4b250818a7fe289508ef9c54c1b48e
14:20zmike: seems like it can't find the loader libs even though I'm passing them
14:20karolherbst: uhh
14:20karolherbst: cmake -G "Ninja" ../ -DCL_LIBCLCXX_DIR=/usr/lib64/ -DCL_INCLUDE_DIR=/usr/include -DCL_LIB_DIR=/usr/lib64/ -DCMAKE_RUNTIME_OUTPUT_DIRECTORY=. -DOPENCL_LIBRARIES=OpenCL -DCMAKE_BUILD_TYPE=Debug
14:20karolherbst: or something
14:20zmike: yea I did that
14:20karolherbst: mhhh...
14:21karolherbst: pastebin the output?
14:21zmike: I got it working
14:22zmike: now to figure out why rusticl exploded
14:24karolherbst: ehh wait... messing with buffer_barrier didn't change a thing, I just messed up my environment
14:25karolherbst: zmike: ohh.. not sure how well things work on radv...
14:25karolherbst: mareko: yeah, seems fine without that si_clear_render_target change
14:25zmike: Requesting GPU device based on environment variable for platform index 0 and device index 0
14:25zmike: ERROR: clGetPlatformIDs failed! ((unknown) from /home/zmike/src/OpenCL-CTS/test_common/harness/testHarness.cpp:403)
14:25zmike: OCL_ICD_FILENAMES=/usr/local/etc/OpenCL/vendors/rusticl.icd CL_DEVICE_TYPE=CL_DEVICE_TYPE_GPU RUSTICL_ENABLE=zink test_conformance/basic/test_basic
14:26karolherbst: huh...
14:27karolherbst: zmike: try OCL_ICD_VENDORS and point to the so file
14:27zmike: no change
14:28karolherbst: looks like the ICD doesn't load rusticl
14:32tnt: I never had any luck with OCL_ICD_VENDORS. Usualy I need to get OCL_ICD_VENDORS to "" (empty) and then set OCL_ICD_FILENAMES to the .so
14:32karolherbst: it kinda depends on what ICD you have
14:33karolherbst: but yeah..
14:33zmike: the icd just has the library so path
14:33karolherbst: what ICD are you using anyway? ocl-icd or that khronos one?
14:34zmike: it's the rusticl icd
14:34karolherbst: I meant the loader
14:34zmike: ocl-icd
14:35karolherbst: mhh.. then OCL_ICD_VENDORS with an absolute path to the drivers so file should work
14:35karolherbst: or just use meson devenv
14:35zmike: no change
14:35karolherbst: are you even building it?
14:35zmike: yes
14:36karolherbst: maybe check with LD_DEBUG=libs then
14:37zmike: oh it's using the khr loader
14:37zmike: but ld debug seems to find everything
14:38zmike: never gets to the point of loading rusticl though
14:38karolherbst: I think the khronos one expect OCL_ICD_FILENAMES to point to the so file...
14:38karolherbst: https://github.com/KhronosGroup/OpenCL-ICD-Loader#table-of-debug-environment-variables
14:38zmike: ok that worked
14:38zmike: 🤕
14:39karolherbst: I should fix that mess in the devenv setup...
14:39zmike: so what am I looking at here
14:40karolherbst: after a call to zink_launch_grid you should see a call to zink_buffer_map
14:41karolherbst: and the memory the returned pointer points to doesn't contain the writes from that launch_grid
14:41zmike: oh gallium trace doesn't work with rusticl
14:42karolherbst: ehh.. I thought I fixed it
14:42zmike: is it the first sequence of launch_grid -> buffer_map that fails?
14:42karolherbst: yes
14:42karolherbst: there shouldn't be a second one anyway
14:42zmike: I'm testing on radv and it seems like it passes
14:42karolherbst: mhhhh
14:42karolherbst: let me check on radv...
14:43zmike: it fails on like the 20th one
14:44karolherbst: mhh.. looks like it's indeed more reliable on my desktop.. uhh
14:45karolherbst: it fails like always on my laptop
14:45karolherbst: maybe it's a bug in anv... but I was seeing fails on my desktop with more GPU load...
14:46karolherbst: ehh wait..
14:46karolherbst: I should have used my local build and not intels' stack..
14:46karolherbst: yeah...
14:46karolherbst: it works more reliable with radv and always fails with anv
14:50karolherbst: zmike: if I keep the AMD gpu busy with other things, it fails more often
14:52zmike: which test case in this thing is failing, specifically
14:53karolherbst: "if"
14:53karolherbst: it's a dead simple test if almost nothing else going on
14:53karolherbst: *with
14:53zmike: hm I'm seeing a bunch of other fails before that one
14:53zmike: but sure
14:54karolherbst: yeah.. it's a general problem
15:13zmike: karolherbst: remind me again what you're doing with the global_binding buffers
15:13karolherbst: pass their raw addresses into the shader via cb0, and the shader might do arbitrary things with it
15:13karolherbst: well.. arbitrary meaning load/stores on global memory
15:14zmike: so it's read-only access?
15:14zmike: or read-write
15:14karolherbst: read-write
15:14zmike: ok
15:17zmike: karolherbst: I think it was not described clearly to me originally
15:17zmike: https://paste.centos.org/view/8e495d05 seems to fix it
15:18zmike: along with all the other tests
15:21karolherbst: okay, cool
15:21karolherbst: I'll run the cts and check if it fixes the problem generally
15:23karolherbst: zmike: I also have this change locally and was wondering if you think it's needed as well: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24839/diffs?commit_id=0f1fdfa62254e49d02e9555632dc6b04b435c20e#2e2fa4b83d660e6375d2148e42efc811e59a3451_1291_1291
15:23karolherbst: or is the stuff done in zink_update_descriptor_refs enough?
15:24zmike: yeah don't do that
15:24karolherbst: okay
15:25mareko: tarceri: do you know if disk_cache has a mechanism that detects file corruption and rejects corrupted shaders?
15:25pekkari: Hi guys, how is the best way to wait a crtc commit to be finished in the kernel side? I tried to use drm_crtc_commit_wait, but I got no big luck
15:27karolherbst: zmike: you want to submit an MR or should I just add a commit in our name to the rusticl/zink one?
15:27soreau: daniels: thanks
15:29soreau: robclark: Thanks for the review, I've been trying to clean it up. Can you say if recreating the fb on each frame is ok or should I be able to do it once upfront and just rebind on each frame?
15:29zmike: karolherbst: just amend it into the other global binding one
15:29karolherbst: ohhh.. yeah.. I thought it already landed...
15:29mareko: dschuermann: would you be OK with adding a hash check into cached RADV shaders to detect file system corruption? or is this something disk_cache should do instead?
15:30karolherbst: done
15:30pendingchaos: it looks like disk_cache_os.c's parse_and_validate_cache_item() does a CRC32 check
15:30karolherbst: zmike: anyway, this was the last blocker, so if that's fine now I kinda want to merge it
15:31zmike: you tell me if it's fine, I'm not running cts
15:31karolherbst: yeah.. I'll run it here also with radv and see if anything else is super broken or if it's fine now..
15:31karolherbst: but it looks better now
15:38zmike: I'll await your feedback
15:39karolherbst: "Pass 2418 Fails 35 Crashes 1"
15:39karolherbst: CL_ADDRESS_CLAMP being like 15 of those...
15:40karolherbst: but yeah.. nothing serious enough to block on merging in
15:40karolherbst: let's see what radv and lvp say
15:41karolherbst: this will take a while, but I think once everything is reviewed it can land
15:41robclark: soreau: recreating each frame is probably not the end of the world on most hw.. but kmsro stuff that needs contiguous scanout buffer might appreciate you not doing that
15:42eric_engestrom: soreau: next time you rebase your kmscube MR, the pipeline will run properly :)
15:42soreau: robclark: I did try simply rebinding the fb, db and textures, but this 'didnt work'. What more do I need to do, set min/mag filters?
15:43soreau: eric_engestrom: thank you!
15:44robclark: oh, I guess you are talking about the fbo you render the gears to, not the one that is scanned out? I think that shouldn't be a problem to recreate
15:45robclark: re: gl.. `MESA_DEBUG=1`?
15:45robclark: or =incomplete_fbo
15:45karolherbst: zmike: list of commits still missing reviews: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24839#note_2101851
15:45zmike: I'm going through them now
15:45karolherbst: thanks!
15:48soreau: robclark: yes, the gears fb
15:50soreau: I still would at least not to glGen/glDelete on each frame but I don't know how much overhead that would save
15:51robclark: I'd probably not worry too much
15:52soreau: ok, thanks
15:54soreau: robclark: renamed the shaders and reformatted to whitespace
15:55pekkari: is it the right place to ask questions about drm_atomic? or is there any other channel for that?
15:55MrCooper: pekkari: this is it
15:55soreau: daniels: the link is wrong on the wiki 'signup page'
15:56pekkari: oh, alright, thanks MrCooper, I asked it a few lines up about how would be the right way to make drm_atomic wait on a crtc commit to be finished
15:57soreau: can anyone confirm going to https://gitlab.freedesktop.org/freedesktop/freedesktop/-/wikis/home and clicking on 'signup page' brings them to an unrelated issue report?
15:58soreau: eric_engestrom: I pushed but it failed instantly again
16:00soreau: oh you did say to rebase
16:00soreau: derp
16:02soreau: eric_engestrom: yes it worked, thanks
16:04eric_engestrom: soreau: hehe
16:04eric_engestrom: you're welcome :)
16:05soreau: :)
16:30soreau: pekkari: you might have a look at kmscube https://gitlab.freedesktop.org/mesa/kmscube/-/blob/master/drm-atomic.c and look around for fences
16:31pekkari:looking, thanks!
16:32pekkari: though I'm looking into the kernel space, not sure if the user space use case will actually help my day
16:39zmike: karolherbst: anything else I need to do at this point
16:40karolherbst: nope
16:40zmike: k
16:43karolherbst: I'll probably run into more bugs once I test more with nvidia's vulkan driver and stuff
17:49karolherbst: uhh.. my new way of loading zink doesn't work on lvp... shouldn't be hard to fix though
17:56karolherbst: mhhh.. works with LIBGL_ALWAYS_SOFTWARE=1
17:56karolherbst: whatever
17:56zmike: shipit
17:56karolherbst: it's just a mess for the script I use to run the CTS on all the drivers and hardware and everything
17:58karolherbst: but I can make that work
17:59soreau: zmike: do you have any idea or comment on why drm backend hard locks the machine with my zink patch?
17:59soreau: my eyes aren't as good as yours
17:59karolherbst: I have to add special handling for nvidia anwyay
18:01zmike: soreau: at a glance I'd say because you're trying to do complicated stuff like run xserver with glamor disabled and modifiers hacked out and hitting codepaths that aren't intended to be hit
18:01soreau: zmike: no, it's glamor enabled
18:01soreau: I got that working with wayland backend at least
18:01zmike: but your device doesn't support modifiers
18:03soreau: well, it works with wayland backend, that's what I know
18:03soreau: but it's clear it's hitting paths that aren't intended for this case, I was just wondering if you had a hunch as to where or what
18:03zmike: I do not
18:04soreau: ok, thanks 👍
18:04zmike: good luck
18:10soreau: btw, when hard locks happen, what's a good way to debug? serial?
18:14zmike: maybe?
18:19soreau: or some watchdog situation
18:22karolherbst: zink intel: Pass 2417 Fails 35 Crashes 2 AMD: Pass 2285 Fails 30 Crashes 139 lvp: Pass 2286 Fails 30 Crashes 138
18:23zmike: at least the fails are consistent?
18:23karolherbst: all crashes are image related...
18:23karolherbst: well.. except the 2 intel also has
18:23karolherbst: it's probably something silly
18:25karolherbst: asserts inside vk_object_base_assert_valid
18:25karolherbst: looks like some invalid handle getting passed around
18:27karolherbst: mhhh, it's inside zink_descriptors_update_masked_buffer, which isn't reached with anv
18:28karolherbst: yeah.. so it's a ZINK_DESCRIPTOR_MODE_LAZY vs ZINK_DESCRIPTOR_MODE_DB thing
18:29zmike: which one is asserting
18:29karolherbst: the call into GetDescriptorEXT
18:29zmike: 🤔
18:29karolherbst: line 1174
18:29zmike: ZINK_DEBUG=vvl
18:30karolherbst: what does this do, because it doesn't print anything to stdout
18:31karolherbst: ohh..
18:31karolherbst: probably I have to properly set up validation layers again.. uhhh
18:31karolherbst: okay, got it
18:32karolherbst: https://gitlab.freedesktop.org/-/snippets/7692
18:33zmike: your vvl is too old
18:33zmike: update
18:46karolherbst: I hope version 261 will be new enough
18:49zmike: that's kinda old
18:49zmike: I think even ci has newer than 261
18:49karolherbst: newest is like 264, no?
18:49zmike: yea
18:49karolherbst: 265 actually
18:50karolherbst: let's hope it's enough because atm it's the easiest thing to install/build, otehrwise I will have to build into a local prefix and that's going to be more pain
18:51karolherbst: but I have currently 238....
18:59halfline: did anyone on dri-devel mailing list get this mail I sent a couple of hours ago? https://paste.centos.org/view/d5ff0b7c I'm not seeing it in the archives. wondering if it got caught in a spam trap or something
19:03javierm: halfline: I don't see in my inbox, nor in patchwork https://patchwork.kernel.org/project/dri-devel/list/?submitter=Ray+Strode&archive=both
19:03javierm: halfline: so it seems that didn't make it
19:04airlied: probably just held for moderator, MrCooper usually processes those when he gets the chance
19:05halfline: weird, i'm pretty sure i've been subscribed to that list for decades, wonder why it went to moderation
19:06karolherbst: uhhh
19:06karolherbst: spirv-tools update broke existing binaries :')
19:07karolherbst: zmike: https://gitlab.freedesktop.org/-/snippets/7692
19:10karolherbst: anyway.. I think it's simply passing either a NULL sampler or the memory is simply not initialized
19:28karolherbst: zmike: yeah... no idea what's going on there. This db_template stuff is quite confusing. The test running into this is `test_basic image_r8`
19:28zmike: checking
19:31halfline: javierm: looks like it's in patchwork now. thanks for the link
19:34zmike: oh
19:34zmike: how did this work at all
19:35karolherbst: ehhh
19:35karolherbst: anv be like: case VK_DESCRIPTOR_TYPE_SAMPLER: /* There is no real limit on samplers */ break;
19:36karolherbst: ehh
19:36karolherbst: maybe different API
19:36karolherbst: but anv takes a different path anyway
19:37karolherbst: anyway.. "ZINK_DESCRIPTORS=lazy" works with lvp as well
19:38zmike: fixed
19:39zmike: pick HEAD off zmike/test
19:40karolherbst: uhhh
19:42karolherbst: looks better
19:51karolherbst: now it's Pass 2374 Fails 40 Crashes 40
19:52karolherbst: will look into the other things tomorrow
20:06karolherbst: radv: Pass 2400 Fails 44 Crashes 10
21:19robclark: this is a fun read.. https://www.hertzbleed.com/gpu.zip/GPU-zip.pdf .. time for MESA_uncompressed_texture gl/vk extension?
21:56dj-death: robclark: ahah :)
22:07airlied: robclark: isn't that just use linear :-)
22:08robclark: well, that is the big hammer approach.. but maybe you'd like to still do tiled
22:08robclark: anyways, that gallium driver part of it shouldn't be so hard (and could fallback to LINEAR based on pipe cap or something like that)
23:11soreau: zmike: I got Xwayland working with RX580 on wayland and drm backends running zink+radv using this patch http://ix.io/4Hwh
23:11soreau: shall I make an MR or is it no good?
23:22zmike: definitely not
23:22zmike: first part is maybe something, idk what you're doing in the second
23:27soreau: zmike: this needs to return true somehow https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/drivers/zink/zink_resource.c?ref_type=heads#L1203
23:28soreau: and it needs to set this https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/drivers/zink/zink_resource.c?ref_type=heads#L756 to VK_IMAGE_TILING_LINEAR or VK_IMAGE_TILING_OPTIMAL depending on the conditional in the patch
23:29soreau: or else glxgears stride is wrong, or otherwise the image is corrupted
23:35soreau: would it not work in the case where there are modifiers supported?
23:36soreau: because IIUC, I think tiling would get set to VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT in that case because EXT_image_drm_format_modifier && modifiers_count
23:38soreau: zmike: if you would prefer, I could make an MR where we can discuss it further on gl
23:45zmike: I'm at the pub so probably that'd be more productive
23:48soreau: super good