03:03jello: hello, is this the right place to get help with a game segfaulting in mesa? I have a backtrace at https://paste.debian.net/hidden/94c65e9e/
09:57yyds: hi, how to determine which X video driver is using. How to do that?
10:00tnt: yyds: check the logs, it should say.
10:04yyds: tnt: I tried: #grep LoadModule /var/log/Xorg.0.log ->glx|nvidia|nouveau|nv|modesetting|fbdev... , I can't determine. 3060ti is my card.
10:06yyds: I also tried nvidia_drm.modeset=0|1, logs looks the same.
10:06tnt: post the log ...
10:07tnt: (on paste bin or such )
10:13yyds: tnt: modeset=1, https://pastebin.pl/view/fa32259d
10:14yyds: tnt: modeset=0, https://pastebin.pl/view/78eebe68
10:16tnt: well it's using nvidia driver when modeset=0 AFAICT ...
10:56yyds: tnt: how to determine it?
11:06tnt: ... it's the driver printing the most stuff in the log and that seems to end up with a sucessfull init ...
11:09yyds: Both log files have many lines "modeset(G0):--blob---"
11:55iyes: Where can I find various general developer documentation for mesa? Whatever would be helpful to figure out the codebase, architecture, apis, dev workflows, etc.? I kinda want to contribute (specifically, with Asahi), but first I gotta find my way around the project. :)
12:04iyes: I mean, if there is anything else besides mesa-docs.readthedocs.io and docs.mesa3d.org . I'm already reading those. I'm asking in case ppl know of more things I should know about. With some projects, there are useful resources that don't show up with a quick google search. :)
12:15FLHerne: iyes: not really documentation as such, but there are a number of developer blogs with some technical detail
12:17FLHerne: https://rosenzweig.io/ https://www.gfxstrand.net/faith/blog/ https://www.collabora.com/news-and-blog/ (don't know if there's a way to filter by graphics content)
12:22alyssa: FLHerne: you're looking for https://planet.freedesktop.org/
12:24FLHerne: I'm aware of it, but that also has a lot of non-gfx content that can't (afaik) easily be filtered out)
12:41alyssa: fair enough
12:41alyssa: my graphics-filtered feed is https://rosenzweig.io/gpu-feed.xml
12:49FLHerne: I guess https://www.supergoodcode.com/ and https://anholt.livejournal.com/ , and Igalia vc4 although again it seems buried in non-gfx posts
12:50FLHerne: and https://airlied.blogspot.com/ and what have I forgotten
13:06iyes: Thank you all! I was disconnected but found an irc log with your responses. Non-gfx-filtered is fine, I'm pretty good at sifting through lots of content/headlines.
15:50i509vcb: I'm trying to figure out which drivers are correct at implementing vkGetMemoryFdPropertiesKHR
15:51i509vcb: some drivers: v3dv, anv and a few others will return VK_SUCCESS regardless of the file descriptor passed in
15:51i509vcb: However it seems bizzare to return VK_SUCCESS for an fd created via open when you'd probably expect a prime fd to only be successful?
15:52i509vcb: (also means -1 being passed into vkGetMemoryFdPropertiesKHR technically returns VK_SUCCESS, but why would an invalid fd be reasonable to pass into that)?
15:53i509vcb: The former with drivers not checking whether an fd is actually a prime fd in vkGetMemoryFdPropertiesKHR feels like a driver issue
15:53i509vcb: but it also feels like a spec issue where fd = -1 is not explicitly said to return VK_ERROR_INVALID_EXTERNAL_HANDLE?
15:54emersion: checking the type of the FD is not enough
15:54emersion: not all DMA-BUFs can be imported by drivers
15:54emersion: what guarantees does the spec offer?
15:55emersion: does the spec specify that the driver will check the handle?
15:57i509vcb: VUID-vkGetMemoryFdPropertiesKHR-fd-00673 states
15:57i509vcb: > fd must point to a valid POSIX file descriptor memory handle
15:57i509vcb: Outside of that I can't seem to find much of anything else
15:59i509vcb: VUID-vkGetMemoryFdPropertiesKHR-handleType-00674 forbids OPAQUE_FD as the handle type, but drivers seem to check for that already and what happens there is effectively undefined behavior
16:00emersion: that is a requirement for the user of the API
16:00emersion: not for the driver
16:01emersion: so i think it's okay for the driver to optimize the case if it always returns the same values for all valid FDs
16:04i509vcb: I guess from that intepretation, if it's not a prime fd then you'll get the error on import
16:08emersion: yeah, but i'm not sure what the guarantees are there again
16:08emersion: sometimes the vulkan spec states that it's UB
16:24DemiMarie: Has the problem of amdgpu not zeroing VRAM been fixed? That’s going to be a serious problem for virtio-GPU native contexts. I’d offer to help but neither know where to even begin nor have any AMD GPUs I could test on.
16:28koike: sima, airlied, robclark (and others), I'd like to check with you how would you prefer to move forward with the ci patch
16:29MrCooper: DemiMarie: it hasn't, but it's being worked on, with the approach I suggested in https://gitlab.freedesktop.org/mesa/mesa/-/issues/9189#note_1972986
16:33robclark: koike, sima, airlied: unless we go back to out-of-tree ci my preference is to land it as soon as possible so that I'm not without working CI ;-)
16:51DemiMarie: MrCooper: will this be mandatory, meaning that malicious userspace cannot subvert it to steal information?
16:54MrCooper: yeah, the point is user space won't be able to allocate un-zeroed BOs
17:12DemiMarie: MrCooper: That is great! I added a comment explaining my use-case and what the consequences would be if the feature was not implemented.
17:14gfxstrand: alyssa: Naming question: For nir_src, we need three operations: Clear, set a cleared things, and rewrite. They need names.
17:15gfxstrand: I don't like init/fini because all of those ops assume it's been at least memset to 0
17:15gfxstrand: I don't like add/remove because the memory already exists, we're just mucking about with the source
17:15gfxstrand: I like clear/rewrite well enough but I don't know what the third should be.
17:15gfxstrand: assign? populate? set?
17:15zmike: wrangle
17:16gfxstrand: fill?
17:16alyssa: gfxstrand: Can we take a step back
17:16gfxstrand: okay
17:16alyssa: Why do we even have unpopulated nir_srcs in the first place?
17:16alyssa: I'm not saying there's not a good reason but I don't understand it
17:17gfxstrand: This generally comes up when adding a source for some reason.
17:17gfxstrand: for nir_tex_instr, we have nir_tex_instr_add_src and that works great.
17:17alyssa: Right
17:17gfxstrand: There's a couple cases where we aren't using it but we could just use the helper
17:17gfxstrand: The one I'm looking at blowing up right now is parallel copies
17:17alyssa: nir_src_init looks unused yeah?
17:18alyssa: oh I see the parallel copy blow up ok
17:19alyssa: gfxstrand: IDK, it looks like any code that's operating on non-filled sources is already failing the smell test
17:19alyssa: luckiy there are only a couple places where NIR_SRC_INIT is used and they're all in the core
17:20gfxstrand: Yeah, I've mostly removed NIR_SRC_INIT
17:20alyssa: I would... strongly prefer requiring that sources are filled at all times
17:20alyssa: and for the oddball cases like parallel copies, IDK, init with nir_undefs if you have to
17:20gfxstrand: Hrm...
17:21gfxstrand: We could possibly fix parallel copies by adding some helpers
17:37gfxstrand: If it really is just phi nodes, I can come up with a plan for those.
17:37gfxstrand: s/phi nodes/parallel copies/
18:52karolherbst: gfxstrand: mhh. so I have this issue, that I have some left over scratch load/stores and I was wondering what's the proper way of getting rid of pointless ones before io lowering. Is it required to call `nir_lower_vars_to_explicit_types` before all of those deref optimizations?
19:28karolherbst: mmhh.. anyway, I'll throw in an optimization loop between explicit_types and lower_io
19:37zmike: Lynne: this feels like a question for you: are there any single frame test clips? ideally some that work with mesa's vdpau?
19:45gfxstrand: karolherbst: You'll have to be more specifdi
19:45gfxstrand: *specific
19:46gfxstrand: alyssa: I'm still running more CI but it looks like it really is just parallel copies that are especially stupid here.
19:51jannau: zmike: `ffmpeg -i $SAMPLE -codec:v copy -vframes 1 $SAMPLE_1frame.$EXT` should generally work. $EXT should be h264, h265 and I think ivf would be the best choice for vp9/av1
19:52zmike: hm
19:52zmike: so let's say I was using big buck bunny
19:53zmike: seems to work
19:53zmike: incredible
19:54karolherbst_: gfxstrand: mhh.. yeah, I had a leftover store+load scratch pair, which my nir pipeline wasn't able to get rid of unless I call explicit_types on function_temp memory before optimizing
19:55alyssa: gfxstrand: \o/
19:55gfxstrand: alyssa: But now I'm headed down a rabbit-hole....
19:55gfxstrand: alyssa: I think we might be able to make NIR faster if we're a little less dumb in nir_def_init()
19:55alyssa: I like faster NIR
19:56gfxstrand: Annoyingly, nir_def_init is used 243 times.
19:57alyssa: gfxstrand: :|
19:57alyssa: Lot of code that should be using the proper builders but isn't?
19:58gfxstrand: Intrinsic and tex builders haven't been around that long
20:02alyssa: yeah
20:02alyssa: and the tex builders aren't really usable in gl
21:40ids1024[m]: <i509vcb> "I guess from that intepretation,..." <- https://registry.khronos.org/vulkan/specs/1.3-extensions/html/vkspec.html#fundamentals-validusage... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/gpNuleeGJPHtyWjKdjJIotZX>)
21:42ids1024[m]: Or well, in this case it specifically depends what "point to a valid POSIX file descriptor memory handle" means (any file descriptor? or only one that's a "valid memory handle"? Which means what?)
22:31DavidHeidelberg[m]: anholt: could I get your R-b on this commit https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23563/diffs?commit_id=e122f0ce63ae5025b88dc6741948b013457ca95d ?
22:33anholt: DavidHeidelberg[m]: ack I guess
22:36DavidHeidelberg[m]: it's just definition, with it can injected kernel can download and use right kernel and DTB :) Thank you