00:48alyssa: Are there any tests for on-screen (or WSI shared) ARB_texture_barrier?
00:48alyssa: neither piglit nor cts seem to cover this case, which is a big gap since I think it hits fun code paths in both iris and radeonsi
00:50alyssa:isn't sure she knows enough EGL to write such a test off hand
00:53airlied: don't remember seeing anything specific to that
01:01alyssa: alright
01:02alyssa: then I'm guessing it's broken in at least some drivers ;-)
01:03airlied: but also in practice nobody has tried it in a real app :-P
01:11alyssa: :clown:
02:11jenatali: 6 Vk CTS failures left to debug on WARP. Then I guess we see where NV's driver is and maybe I can actually get conformance soon
02:12jenatali:is ready to remove -experimental from the meson command line and the nom-conformance debug warning
02:13HdkR: \o/
02:15gfxstrand: \o/
02:15gfxstrand:is hoping to remove it from NVK soon, too.
02:19jenatali: These are all new tests from the older CTS snapshot I had been running. Feels disingenuous to try to claim conformance with something so old
02:25alyssa: jenatali: :D
02:26alyssa: jenatali: how many failures running dozen on vkd3d-proton on dozen on warp/
02:26alyssa: :P
02:26jenatali: I haven't tried, sounds slow
02:27alyssa: :S
02:28alyssa: :D
02:28jenatali: I finally found out the test machine I'd been using had been underclocking itself which is why it was so bipolar between being speedy and painfully slow
02:49kisak: nom-conformance <- the cats fetting to you?
02:49kisak: *getting
03:04jenatali: kisak: that's what I get for typing on a phone
03:05ccr: mlem- and blep- conformance
07:54vsyrjala: drm_buddy kunit stuff is apparently got broken in -rc1. is someone fixing that?
07:54vsyrjala: mairacanal: ^ ?
07:54vsyrjala: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14150/shard-mtlp-8/igt@drm_buddy@drm_buddy@drm_test_buddy_alloc_limit.html
11:53mairacanal: AnuthaDev, I'm not planning to take mentees this year :(, but we can chat on #videocore if you have any doubts about the driver
11:54mairacanal: vsyrjala, I'll take a look into that in the end of the day
12:41vsyrjala: mairacanal: here's another one perhaps https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14150/shard-mtlp-8/igt@kms_selftest@drm_format_helper@drm_format_helper_test-drm_test_fb_build_fourcc_list.html
12:42mairacanal: maybe grillo_0 has the interest to work on some of those issues, anyway I'll take a look later
14:23javierm: vsyrjala, mairacanal: how does igt run the kunit tests? Asking because I just ran the kunit tests with v6.8-rc1 and all tests passed
14:24javierm: this is with `make ARCH=um mrproper && /tools/testing/kunit/kunit.py run --kunitconfig=drivers/gpu/drm/tests/.kunitconfig`
14:25mairacanal: maybe an issue with lib/igt_ktap? or an x86 issue?
14:26javierm: mairacanal: let me try with x86
14:35javierm: mairacanal: [15:34:49] Testing complete. Ran 390 tests: passed: 390 with `./tools/testing/kunit/kunit.py run --arch=x86_64 --kunitconfig=drivers/gpu/drm/tests/.kunitconfig`
14:35javierm: so don't know why it fails with IGT tbh
14:36mairacanal: are you running drm-misc-next or 6.8.0-rc1?
14:37javierm: mairacanal: tag: v6.8-rc1
14:37javierm: mairacanal: also tested with drm-misc-next btw and didn't find any issues
14:38mairacanal: yeah, I'll have to investigate any changes in the ktap output
14:38mairacanal: maybe the parser is not working properly anymore
14:39javierm: mairacanal: Ok
14:47jani: what if you could pass basically any drm object to the drm_dbg_*() macros, and if they had obj->dbg hook set, they'd use that, and fall back to obj->dev (struct drm_device *) debug logging?
14:49jani: e.g. struct drm_connector could have a dbg hook that would print with the usual [CONNECTOR:%d:%s] format, using &connector->dev->dev device
14:49jani: ditto for drm_crtc and drm_encoder etc.
14:50jani: drm_dbg_kms(connector, "...");
14:57emersion: sometimes the [CONNECTOR:…] thing is in the middle of the string, sometimes there are multiple
14:58emersion: maybe we could have a simple obj->dbg string field instead?
14:58emersion: hand-rolling these it definitely cumbersome
14:58emersion: is*
15:01daniels: that's a _really_ good idea
15:01vsyrjala: i've occasionally thought about adding _FMT/_ARGS() macros for these, but those aren't very nice either
15:04vsyrjala: i guess one could propose custom printk() conversions for them, but dunno how big the bikeshed would be
15:10jani: the non-display side of i915 and xe have accumulated a crazy amount of foo_dbg() macros for various foo things. I'd like this to be a model that could perhaps be replicated for things not in drm core. i.e. "just" add a hook in the object and it'll get used.
15:11jani: err, obviously I don't want the proliferation of new foo_dbg() to be the model! :)
15:12jani: and feels like just adding format strings isn't going to be enough or pretty
15:15jani: I guess you could just call e.g. connector->dbg() directly too, but with _ratelimited and _once versions, maybe going through macros is better
15:16emersion: you could maybe also go through _Generic magic if you really wanted to…
15:17jani: vsyrjala: regarding custom printk conversions, I personally think those have gotten out of hand (there are just way too many) and they're not very usable because it's a random sequence of meaningless format characters
15:18jani: emersion: yes. it's just that neither checkpatch nor sparse have properly caught up to them. not a show stopper, but a minor nuisance
15:20vsyrjala: i certainly hate all the "print this integer but pass it as a pointer" printk crap
15:20vsyrjala: but i kinda wish we had a register_printk_function() for stuff where it makes sense
15:23jani: vsyrjala: either that, or "%p{what-in-plain-english}" instead of %peLefweföwhatever
15:28Company: if I want to use GL to render to a dmabuf (on Wayland), how would I do that?
15:28Company: What's the recommended method?
15:28emersion: import as EGLImage, bind to FBO, render to FBO
15:29pq: no wayland needed
16:53orbea: What is the best project to report this backtrace to? mesa? vulkan-loader? Parallel-RDP? (n64 vulkan plugin) https://github.com/Rosalie241/RMG/issues/219
16:57alyssa: orbea: mesa, aco tag
16:57alyssa: dschuermann: ^^
16:57orbea: thanks, I'll make one in a moment
16:58alyssa: It's entirely possible that the vulkan app is broken too
16:58alyssa: but that backtrace indicates with almost-certainty an aco (radv compiler) bug
17:00orbea: fwiw the vulkan code is here https://github.com/Themaister/parallel-rdp (or the autogenerated repo that is vendored in RMG: https://github.com/Themaister/parallel-rdp-standalone)
17:12orbea: it also segfaults with RADV_DEBUG=llvm .... rebuilding llvm with symbols now which will take a bit
17:18alyssa: curious
17:32Company: emersion: hrm, but then I need to create the dmabuf myself, don't I?
17:33Company: which was a thing I was hoping GL (or EGL) would do for me
17:49MrCooper: Company: "I want to use GL to render to a dmabuf" kind of implied you already have a dma-buf :)
18:01any1: libgbm
18:12daniels: Company: yeah you only use (E)GL to import, not allocate
18:17Company: MrCooper: what I want is make GtkGLArea not draw to a random GL texture, but to a dmabuf, so that I can use it for graphics offload (which is GL only) and with the Vulkan renderer (where I could use Vulkan to allocate the dmabuf)
18:21Company: figuring out how to handle GLArea with the Vulkan renderer is one of the big questions before we can switch the renderer to Vulkan more aggressively
18:22Company: I mean the interop works, but it goes via glReadPixels() so it's not the fastest...
18:32mareko: daniels: wayland-protocols is just a subproject of Mesa for #includes that doesn't need to be installed, right?
18:33mareko: daniels: if so, Mesa can fetch it for builds in subprojects/
18:33daniels: mareko: yes, it’s a build-time provider of XML and nothing else
18:33daniels: (which is why I was so surprised to be told that I couldn’t use any version not shipped in Ubuntu LTS-1)
18:34mareko: daniels: my local Mesa build already seems to be set up to use wayland-protocols from the subproject directory, but I don't remember how it works
18:35daniels: mareko: good news - so it’s ok to use newer versions from your pov?
18:35mareko: it looks like it
18:36mareko: see https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25683
18:37mareko: I guess the file needs to be updated for any requirement updates
18:51Calandracas: Is this the right place to ask a rusticl question? I'm trying to figure out which extensions are supported, but unfortuneately documentation on rusticl has been hard to find
19:30austriancoder: Calandracas: https://mesamatrix.net/ has some information which is based on mesas features.txt
19:39Calandracas: Thanks. The extension I'm looking "cl_ext_cxx_for_opencl" for is not even listed :(
19:42karolherbst: Calandracas: do you actually have a use case for it?
19:42karolherbst: it's not really a registered extension, so I'm reluctent of supporting it
19:43Calandracas: Online compilation of clcpp. Currently im compiling the clcpp with clang, then llvm-spirv
19:43karolherbst: well.. that's the prefered way of doing things anyway
19:43alyssa: I mean, that's the same thing rusticl would do too
19:43Calandracas: It's more of a convinience thing while developing
19:43alyssa: :p
19:44karolherbst: Calandracas: I think build systems should just support compiling to SPIR-V tho
19:44karolherbst: providing SPIR-Vs to the runtime lowers overhead of compilation at runtime
19:44karolherbst: and you make sure at compile time that the source code is valid
19:44Calandracas: Yeah I'll figure out how to set that up with Meson
19:44karolherbst: yeah...
19:45karolherbst: I was thinking of looking into it myself, but didn't get to it
19:45karolherbst: but it would be cool if OpenCL C(++) could be compiled similiar to libraries and you just get the spirv and stuff
19:45Calandracas: i 100% agree that its better to compile to spirv offline, this was really jsut a matter of convinience while developing
19:45karolherbst: the issue with cl_ext_cxx_for_opencl is just, that almost nothing uses it so it would get 0 testing
19:46karolherbst: and the OpenCL CTS has one test for it where it compiles the most trivial kernel possible
19:46karolherbst: yeah...
19:46karolherbst: I think I just prefer build systems to make it convenient instead
19:47karolherbst: I'm not strictly against supporting cl_ext_cxx_for_opencl, I'd just rather not if there are better alternatives. Though I think on android it's apparently a thing so I might have to support it sooner or later
19:47Calandracas: especially since templates increase the compile time signifiantly, online compilation would be really bad for realeases
19:47karolherbst: yeah...
19:48karolherbst: but anyway, rusticl would need to support that ext if there are applications using it, so there is that...
19:48Calandracas: I'm new to meson, but I'll try to figure out how to set it up.
19:48karolherbst: are you using meson for your project?
19:49Calandracas: Yeah
19:49karolherbst: but anyway.. I think I'd prefer if one could just declare "opencl-c' and 'opencl-c++' as languages
19:49karolherbst: but....
19:49karolherbst: I think that needs changes to meson
19:49karolherbst: would be a fun project tho
19:50karolherbst: painful part is to deal with declaring what spirv extensions are allowed... mhh
19:51karolherbst: Calandracas: ohhh... btw I think since clang-17 you don't need to invoke `llvm-spirv` directly
19:51karolherbst: just use the spirv target and the output is the spirv
19:52karolherbst: (it executes llvm-spirv internally) and I think with clang-18 and the enabled spirv target it doesn't even need that
19:52Calandracas: I guess a usecase for online compilation would be querying the device capabilities and tuning the code at runtime
19:52dcbaker: Calandracas: karolherbst I’d review patches for OpenCL as a language. I’ve also thought about adding a graphics module for things like spirv, so that might be appropriate too
19:53karolherbst: Calandracas: yeah...
19:53Calandracas: Oh nice, I'm on clang-17 so I'll try that out
19:53karolherbst: Calandracas: though in theory OpenCL doesn't require _valid_ spirv, so you could spec constant code paths for extensions....
19:54karolherbst: Calandracas: yeah.. need to use spirv not spir as a target tho I think
19:54karolherbst: both works with llvm-spirv anyway
19:54karolherbst: (if compiled with emit-llvm)
19:55karolherbst: dcbaker: yeah.. we might be able to ditch some of the clc compilers we have in mesa with that...
19:56Calandracas: nice i can compile straight to spirv with clang-17, that will make things easier to integrate with meson
19:56karolherbst: :)
19:56karolherbst: it might already work with clang-16, not quite sure when they added support for that
19:57karolherbst: be careful with the SPIRV target in clang-18 tho, as it still generates some invalid spirv, so no idea how well that will work in the future
19:58karolherbst: I also don't know if you can toggle SPIRV extensions this way...
19:58Calandracas: I hope that clcpp catches on. Having template libraries will be really cool
19:59karolherbst: yeah... though I just hope that the LLVM SPIRV target becomes more reliable and that it's easier to use with any language LLVM supports, but yeah...
20:01Calandracas: Anyways thanks for the insight, I really appreciate it
20:01karolherbst: np
20:03alyssa: dcbaker: I guess for vk integrating glslang would be cool too?
20:03karolherbst: alyssa: the painful part here is, that almost all of the other CL impls convert spirv to LLVM IR internally 🙃
20:04alyssa: karolherbst: I just mean for vk apps using meson, they need to do a bunch of buildtime glsl->spirv
20:04karolherbst: ohh, it was in regards to your earlier comment
20:05karolherbst: but yeah.. I think we need to add "producing spirv files" as core features to build systems anyway :P
20:07karolherbst: dcbaker: btw, I still want to see my other PR landing which is blocked by the containers not building situation :P
20:08orbea: alyssa: i made an issue if you are interested https://gitlab.freedesktop.org/mesa/mesa/-/issues/10488
20:08dcbaker: karolherbst: yeah. There’s several important rust things that need to land, yours is one of them
20:08dcbaker: I’ve just been busy working on mesa, lol
20:09karolherbst: heh
20:16Calandracas: nice, it was pretty trivial to add a custom target to compile to spirv in meson
20:17karolherbst: cool
22:38jenatali: Oh. I was unauthed, cool
22:39HdkR: Welcome back
22:39jenatali: Thank you
22:40jenatali: Is there some standard approach in Vulkan drivers for dealing with internal draws/dispatches, to not have them increment statistics counters?
22:40jenatali: I've just discovered statistics_query.clipping_invocations.primary.blit_between_incompatible_formats and it makes me very sad
22:46alyssa: you have hw counters? :clown:
22:46jenatali: We have counters that claim to come from hardware, yeah
22:47karolherbst: what makes you sad about blit_between_incompatible_formats?
22:47jenatali: I could play the same games I do in gallium but ugh that seems like so much overhead for such a corner case
22:47jenatali: karolherbst: It issues a blit that must not increment draw pipeline stats counters. That's much harder to hide in Vulkan
22:48jenatali: Like, I could switch blits to compute but that's just moving the problem around, not really fixing it...
22:48dj-death: jenatali: on intel we can program the HW to prevent it from incrementing the counters for internal ops
22:48karolherbst: yeah.. on hw you can just turn off/on counting that stuff normally
22:49jenatali: Bleh
22:49karolherbst: jenatali: you could enqueue a compute shader substracting what the blit would have added.....
22:49jenatali: Literally my last CTS failure on WARP and that's like days of work
22:49karolherbst: add a new API to WARP instead?
22:49jenatali: karolherbst: Yep. Considering it. Seems cheaper than stopping and restarting
22:50karolherbst: on nvidia we can't count compute shader invocations, imagine that fun there
22:50karolherbst: anyway... fixup shaders should do the trick :D
22:50karolherbst: the pain part is that in vulkan this is actually specified and tested, and GL it was all very yolo
22:51jenatali: At least gallium has driver entrypoints for pause/resume
22:51karolherbst: mhhh.. right
22:52jenatali: Oh well. I'll figure something out
22:53alyssa: don't look at the code i wrote for asahi
22:54gfxstrand: jenatali: Disable counters around meta stuff
22:54gfxstrand: There's no magic for it, unfortunately.
22:54gfxstrand: Vulkan query pools don't exactly have a puase/resume
23:06jenatali: Yeah, D3D doesn't have a "disable counters" function. Which means I either get to go with splitting queries and summing, or counting meta independently and subtracting
23:06gfxstrand: Yeah...
23:06gfxstrand: Vulkan doesn't either
23:09alyssa: on a tiler, enabling/disabling those counters splits your render pass :clown:
23:13airlied: oh I vaguely remember writing some of zink_query.c, not fun times
23:14gfxstrand: That's okay. You can't do meta mid-render-pass
23:15airlied: jenatali: zink_query might be a good model, it does suspend/resumes for blits/clears
23:19jenatali: airlied: Yeah that's how the d3d12 gallium driver works too
23:19jenatali: It's just... a lot of work, especially in a world of query pools instead of individual queries
23:20jenatali: I think I'm going to count meta independently and subtract. I could probably even compute meta's counter values CPU-side
23:21gfxstrand: That's not a horrible idea, TBH.
23:21gfxstrand: Probably easier than trying to suspend/resume.
23:21gfxstrand: Well, hrm...
23:21jenatali: Yeah. Just snapshot the meta counters at begin, subtract them at end, issue a fixup compute shader at resolve time
23:21airlied: zmike: would a vk extension help here?
23:21gfxstrand: Actually, that gets tricky...
23:22jenatali: Eh, no that doesn't work, you can resolve in a separate command buffer, can't you...
23:22gfxstrand: Yup and you can have multiple, say, occlusion queries going at once
23:22jenatali: Right, which is why splitting is a pain
23:23jenatali: I'm half tempted to just switch meta to compute instead. There's no test for that (yet). Much easier than mucking with counters for a single test...
23:24zmike: airlied: ?
23:24zmike:struggles to catch up
23:24gfxstrand: jenatali: Not a horrible plan, TBH
23:24jenatali: zmike: tl;dr dzn has the same problems with queries and internal draws that zink has
23:24gfxstrand: Except dzn is trying to implement Vulkan so 10x worse
23:24jenatali: Right
23:24zmike: zink doesn't have those problems
23:25gfxstrand: How much meta do you have? Just CmdBlitImage?
23:25gfxstrand:thinks CmdBlitImage was a mistake
23:25zmike: internal draws go through u_blitter which already disabled queries
23:26jenatali: gfxstrand: That's the only one that's graphics. There's a few dispatches, but we've added features to D3D to make the dispatches go away
23:26jenatali: zmike: Just the infrastructure for disable/enable
23:27gfxstrand: Yeah, doing CmdBlitImage as compute is probably fine. Intel will suffer but I'm having trouble caring.
23:27zmike: the hard part of queries is avoiding duplicated query execution
23:27zmike: everything else is easy
23:27jenatali: gfxstrand: Is someone just going to add a new test that says that blits can't increment compute invocation counts? (:
23:27gfxstrand: jenatali: Maybe
23:27gfxstrand: I'm not going to. :)
23:28zmike: I'd guess there should be tests for that already in vkcts
23:28zmike: they exist for gfx queries at least
23:28jenatali: zmike: There's not. Literally only clipping invocations
23:28zmike: huh
23:28zmike: I should file coverage then
23:28jenatali: My last CTS fail :(
23:30ccr: "you have failed me for the last time .."
23:34HdkR: "I see you're trying to pass conformance. I have a few tests to add."
23:35zmike: eh they'd be in a future tag anyway so it won't affect this
23:36jenatali: Yeah, but I'd rather not have to rewrite this again later on to pass that new test too
23:38zmike: smart
23:39ccr: "I am altering the the conformance test suite .. pray that I don't alter it any further."
23:39ccr: -the
23:41jenatali: Wait.. https://registry.khronos.org/vulkan/specs/1.3-extensions/html/chap18.html#queries-operation-undefined
23:41jenatali: Is this test even valid?
23:42gfxstrand: jenatali: Good question! File a bug?
23:42jenatali: On the CTS?
23:42gfxstrand: Ugh... Someone should probably file it for you...
23:42gfxstrand: And I'm not long on spoons today
23:44jenatali: I can file it publicly. I can file internally but my legal group probably wouldn't be happy about that (:
23:44jenatali: I had to get gitlab access for the not-public GL CTS tests
23:45jenatali: Ok I did look at the history of the test. zmike looks like you requested it, but the spec says it's invalid
23:46gfxstrand: Hah!
23:46Sachiel: sabotage!
23:47gfxstrand: He just doesn't want to have to debug Zink on dozen
23:47jenatali: :P
23:48zmike: might have been valid when I requested it
23:48gfxstrand: I think that spec language has been there for a while
23:49gfxstrand: Yeah, git blame says that's been there since 2016
23:50jenatali: Is it worth filing a public issue on that? Or would one of you be willing to raise it on gitlab on my behalf?
23:52zmike: I assume gfxstrand did it in the course of spec blaming
23:52gfxstrand: Yeah, it's in the original 1.0 spec
23:52gfxstrand: What's the name of the test?
23:52jenatali: dEQP-VK.query_pool.statistics_query.clipping_invocations.primary.blit_between_incompatible_formats
23:53gfxstrand: Is that the only one?
23:54jenatali: Yep
23:55gfxstrand: jenatali: vk-gl-cts/-/issues/4911
23:55jenatali: Thanks! I owe you one
23:56gfxstrand: Now back to trying to figure out why this silly tessellation subgroup test is failing