00:36Fya: Thanks jenatali. I found the llvmpipe json file name. (lvp_icd.x86_64.json) Which I looked up in pkgfile. The package I needed was "extra/vulkan-swrast".
00:36Fya: Cheers.
00:41kisak: My understanding is that lavapipe was designed so that it could be backed by different implementations and coincidentially only has llvmpipe backing it right now, which is why it shows as llvmpipe when asked by tools.
02:40karolherbst: kisak: no, the intention was for llvmpipe to be the only driver supported from the start
02:41karolherbst: though in theory it would be possible, but I doubt such an MR doing that would ever land
07:05Lynne: is BDA expected to be particularly slow on NVK?
07:05Lynne: I'm getting speeds about a hundredth of the binary drivers when using BDA heavily
08:20jfalempe: sima, tzimmermann, javierm: I don't plan more work on drm_log, can you please review it? https://patchwork.freedesktop.org/series/136789/
08:31javierm: jfalempe: sure, I'll do it later today
08:32jfalempe: javierm: thanks :)
10:08tzimmermann: jfalempe, i'd just leave it the parameter blank. once you commit to 'none' or any other string you cannot go back.
10:09tzimmermann: but your 'none' comment made me thought that we might want something like 'blank' at soem point. it would init and clear the display without further output
10:09tzimmermann: that could easily be implemented as DRM client
10:10tzimmermann: no idea if that is useful
10:46thellstrom: tursulin: There appears to be a conflict in the drm-tip drm-intel-next merge that stops me from fixing the conflict in the drm-xe-next merge. Is that from your drm-intel-fixes picks?
10:55tursulin: thellstrom: quite possibly, I left push-branch unattended and forgot about it
11:00thellstrom: OK. I'll see if it's possible to temporarily use an override commit for drm-intel-fixes to resolve drm-xe-next.
11:30tursulin: thellstrom: I am compile testing the conflict resolution
11:30tursulin: expect to be able to push it shortly
11:31thellstrom: tursulin: I think rodrigo already pushed something there. Although I'm a bit afraid my xe conflict resolution might have resolved also the intel one in an incorrect way.
11:32thellstrom: Let me see what happens when I run rebuild-tip.
11:33stsquad: can anyone explain what the following means?
11:33stsquad: # glxinfo -B -display :0
11:33stsquad: name of display: :0
11:33stsquad: Error: couldn't find RGB GLX visual or fbconfig
11:34stsquad: I'm trying to fix buildroot's Glxinfo test before writing one for vkmark - but it relies on an X session starting and then tickling it from the serial console
11:34stsquad: I can see X is confused looking for swrast which is deprecated
11:35tursulin: thellstrom: oh... my went through so lets hope there isn't a 3-way confusion now
11:35stsquad:also wonders how such a test might work with wayland/weston needing to be up to run vkmark
11:35tursulin: rodrigovivi: you fixed the drm-tip conflict in intel_dsb.c before me?
11:36thellstrom: rodrigovivi: tursulin: Now everything merges fine and the xe conflict is gone, so we just need to check the intel one is correctly resolved.
11:38thellstrom: If not we probably need to revert my drm-rerere commit and I'll push a better one.
11:45thellstrom: rodrigovivi: tursulin: AFAICT everything looks ok.
11:47pq: stsquad, weston can run with its headless-backend, for instance. Then it's completely self-standing, no need for DRM KMS or any parent window system, while still using GPU hw drivers or llvmpipe as needed.
11:49pq: stsquad, you could use weston/headless to run Xwayland in order to test X11 clients with hw accel or llvmpipe.
11:49pq: or rather let weston start Xwayland automatically as needed.
11:51stsquad: pq: I don't suppose you can point at any example headless invocations?
11:53pq: hmm, weston's own test suite does that, but it's a bit tangled off-hand. I don't suppose Mesa had a test?
11:55stsquad: I guess it would be something like: weston -B headless -- vkmark
11:55pq: stsquad, the main things are --backend==headless --renderer=gl
11:55pq: something like that, yeah
11:56pq: oops, should be --backend=headless
11:57pq: you may want --width= and --height= too for the resolution
11:57thellstrom: rodrigovivi: tursulin: Looks like there is a compilation failure in intel_dsb.c, though.
11:59pq: stsquad, and --refresh-rate=
11:59pq: those are all in 'man weston'
12:02pq: stsquad, the default shell is 'desktop'. If that causes inconvenience by its window management opinions, you can try if --shell=kiosk is better.
12:03pq: stsquad, most of these and more can be set in a weston.ini file, too.
12:03tursulin: thellstrom: curious because I built it before to check and built it just now again
12:05daniels: also you really want --idle-time=0 if you're on d-s
12:08thellstrom: tursulin: It might be there were more pushes since I rebuilt. Let me check.
12:12thellstrom: tursulin: If I run dim -d rebuild-tip and then compile the resulting drm-tip, then I still see a compilation failure.
12:13thellstrom: https://www.irccloud.com/pastebin/fP7HOCFq/
12:23tursulin: thellstrom: oops I was building with the wrong .config :facepalm:
12:23tursulin: I guess rerere is then bad
12:33tursulin: I am reverting Rodrigo's rerere commit and re-doing it, stay tuned
12:39tursulin: thellstrom: should be fine now
12:46thellstrom: tursulin: Yes, looks ok!
13:00stsquad: looks like weston -B headless --renderer=gl --shell=kiosk -- vkmark does the trick
15:07gryffus: Hey guys, I tried to build the newest version of AMDVLK on my system (Mesa 24.3.0 and kernel 6.11.8), but I keep getting "terminator_CreateInstance: Received return code -3 from call to vkCreateInstance in ICD /usr/lib64/amdvlk64.so. Skipping this driver." error when trying to launch vulkaninfo with VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/amd_icd.x86_64.json. Anyone has a clue what could be wrong or where should I look for problems?
15:17HdkR: gryffus: Mesa doesn't cover amdvlk so you may not get much help here
15:18Company: and -3 is VK_ERROR_INITIALIZATION_FAILED
15:19Company: and that error is from libvulkan itself
15:19Company: so you will have to make the AMD driver dispense more information somehow
15:30gryffus: Company: https://paste.opensuse.org/pastes/0971c6409187 unfortunately did not yield much more information :(
15:31gryffus: HdkR: I know, but I could get at least some hints, like Company did :))
15:32HdkR: gryffus: Hopefully it is just the issue that amdvlk aggressively cuts out older GPU compatibility. So it only claims support for RX 5000/6000/7000 today.
15:32gryffus: https://paste.opensuse.org/pastes/736dde120246 and with *debug included
15:33gryffus: HdkR: I am running "[AMD/ATI] Cezanne [Radeon Vega Series / Radeon Vega Mobile Series] (rev d1)" which should be supported
15:34HdkR: gryffus: AMD dropped polaris and vega support back in October of last year
15:34HdkR: Would need radv instead of amdvlk
15:35gryffus: Meh.... So I was googling outdated info :( Ok, thanks so much for clarification HdkR and sorry for wasted time :x :D
15:35HdkR: At least Vega is Vulkan 1.4 conformant in radv
15:37gryffus: Yeah I did not have any stability issues or such, I just wanted to benchmark my system and compare the two drivers, expecially on ray tracing (trying phoronix test suite)
15:38gryffus: But yeah it makes total sense why the 2023 AMDVLK worked and recent did not :(
15:39gryffus: Thanks for the help anyway... And RADV for the win! :)
16:04rodrigovivi: tursulin: sorry for the mess and thanks for fixing it...
16:52robclark: tursulin: idk if you often have kmemleak check enabled? I'm seeing job leaks due to what appears to be ->job_free() not getting called after job_run() returns for dynamically torn down schedulers/entities. Not sure if this rings a bell?
16:56tursulin: robclark: I normally do but it doesn't ring a bell I'm afraid. The only reported leaks I vaguely remember seeing rather regularly are about drm connectors, I think. And that is with amdgpu.
16:57tursulin: And if you think vaguely and regularly are a contradiction it is only because for the last few weeks I was in a phase where I had to turn of debugging aids.
16:58tursulin: rodrigovivi: no worries, it was a silent conflict and I can totally understand not feeling the need to build test after fixing a comment :)
16:59robclark: hmm, I kinda suspect that drm_sched_entity_flush() is maybe only flushing things as far as job_run() but not job_free()? I guess I'm going to have to actually look at how this works again
17:13tursulin: robclark: I think so, running jobs ("scheduled"/job_run() executed) will be freed asynchronously when fence callback schedules the free worker
17:14tursulin: modulo any known (not to me) and unknown bugs
17:18robclark: tursulin: in this case, it is for vm_bind queue some returned fence is NULL.. but that should be a pretty common pattern, so I'm a bit surprised that no one noticed this yet.
17:19tursulin: robclark: which driver you are talking about?
17:20robclark: tursulin: msm (with not yet posted patches).. but I guess it should be similar with other drivers using gpuvm + sched based vm_bind queue
17:21tursulin: I think Philipp Stanner was looking into the flush and fini "funs".. don't know his nick here
18:25robclark: tursulin: ok, so calling drm_sched_stop() before drm_sched_fini() seems to resolve it
19:14rodrigovivi: tursulin: yeap, that was exactly the feeling, but lesson learned... thanks
19:56alyssa: i'm rereviewing https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32398 and now i'm kind of wondering, how does float controls2 work with algebraic?
19:56alyssa: if the is_used_by_float has denorms preserved by the builder default flushes denorms, the rule is unsound. can that.. happen?
19:58alyssa: the short answer is that "denorm preserve cannot change per-instruction, so it's fine"
19:59alyssa: fair enough. I guess it's fine then
20:01glehmann: yeah, denorm mode per instruction would be mildly insane
20:03alyssa: tbf so is signed zero / nan per instruction
20:05alyssa: like I know how we got here but still
20:07glehmann: I'd argue that those are useful per instruction
20:08glehmann: and we should really everything but the per instruction flags from nir
20:08glehmann: ...something for next year me, I guess
20:10alyssa: Parsing error on line 2
20:12glehmann: the missing verb is remove
20:13alyssa: ah
20:17glehmann: and then I want to write a pass that removes flags if inputs/outputs can never be nan/inf or if signed zero doesn't matter, to allow more optimizations for dxvk/vkd3d-proton
20:28alyssa: ooh, yeah
20:29alyssa: dovetails nicely with nir_opt_varyings, I assume
20:49dcbaker: cwabbott: I've got "1b42bc76da ir3: Fix reload_live_out() in shared RA" nominated for 24.3, but there's been enough changes between the branchpoint and now it needs a backport to apply. Do you want to send a backport PR, or do you want me to drop it?
20:50dcbaker: olv: ping regarding "d35002949 panvk: expand top-of-pipe and bottom-of-pipe"
20:52dcbaker: hakzsam: I think I forgot to ping you about "08c9dca8db radv: fix skipping on-disk shaders cache when not useful", which is nominated for 24.3 and doesn't apply. Do you want to provide backport PR, or do you want me to drop it?
21:08cwabbott: dcbaker: it's a trivial backport, git just gets nervous that the line after the hunk I added was changed on main compared to 24.3 but it's fine
21:11cwabbott: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32468
21:12cwabbott: hopefully I got the right target branch
21:43olv: It's ok to skip. It should be easy to backport, but panvk has other issues which makes backporting less interesting imo
21:48alyssa: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32398#note_2685944
21:48alyssa: I... don`t know what that means
21:48alyssa: "Unexpected exception in bot while handling this MR'
21:49alyssa: *some* MRs are getting thru so it's not a total Marge outage
21:50alyssa: uh.. -> #freedresktop i guess
21:51dcbaker: cwabbott: looks great, and its the right branch :) It looked like one of the functions had changed number of arguments? Thanks for doing the backport
21:51dcbaker: olv: okay, I'll drop it then
21:52cwabbott: dcbaker: the function called right after the hunk I added had changed the number of arguments
21:52cwabbott: but that doesn't matter for what the change is doing
21:53dcbaker: ahhh, for some reason that looked like it was part of the change when I looked at the diff