01:10alyssa: Sachiel: i support this plan
07:18sima: emersion, c62b758bae6a ("fcntl: add F_DUPFD_QUERY fcntl()")
07:18sima: landed in the upstream kernel, in case you missed that
15:10zmike:falls into the zombie_shaders hole and dies
15:25tnt: On an Intel ARC, anyone know what modifier a texture exported to dmabuf ends up with if it's created by mesa as Tile64 format ?
15:29dj-death: tnt: none I guess
15:29dj-death: tnt: there isn't one defined in drm_fourcc.h afaics
15:32tnt: dj-death: Yeah. I'm wondering if somehow that buffer could end up being converted to linear before being exported ?
15:33dj-death: you can probably do a blit into a linear image yeah
15:34tnt: For a bit of context, I'm working with the intel-compute-runtime stack and sharing buffers (getting them from mesa). The current code only recognize modifier is 0 or !=0 and if it's not 0, then it will pick it's own tiling format and for Arc it picks Tile64 ATM.
15:34tnt: So in the current mesa, you end up with mesa picking Tile4, intel-compute-runtime trying to access it as Tile64 and that doesn't work (obviously).
15:35karolherbst: tnt: what's the set modifier in the texture info though?
15:36karolherbst: mesa_glinterop_export_out.modifier to be precise
15:36tnt: But then a user tried applying some MR that makes mesa pick Tile64 by default ( https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29244 ) and that worked. Which I don't understand _HOW_ because AFAICT, the export should either have failed or returned a modifier == 0 (in which case the compute runtime would have tried accessing it as linear).
15:36tnt: So I'm trying to figure out why it works ... because it shouldn't AFAIU.
15:37tnt: karolherbst: I don't know ... I don't have the hardware, all I know is the user applied that MR and it started working and I'm trying to figure out WTF is happening.
15:37tnt: https://github.com/intel/compute-runtime/issues/736
15:37karolherbst: tnt: well.. the compute runtime should just use whatever the modifier field is telling it to use. If that mismatches with the actual format, or the compute-runtime doesn't respect modifier, then something with that communication is going wrong
15:38dj-death: I'm guessing there no modifier involved in that case
15:38dj-death: otherwise Mesa wouldn't have picked Tile64
15:38karolherbst: mesa creates the resource
15:38karolherbst: and exports it
15:39karolherbst: (and on creating time it doesn't know it might get exported)
15:39dj-death: so this is GL?
15:39karolherbst: GL to CL
15:39karolherbst: but the mesa extension we have to query texture properties does tell what modifier to use on the import side
15:40tnt: karolherbst: yeah, it should do that, I know but ... the place where I get the modifier and the place where it picks the memory format are not even in the same codebase (it's in a sublibrary) and there is a gazillion C++ templatized code I can't follow in between. ATM the only thing it support is a boolean flag "isLinear" which I fill with (modifier == 0) and hope for the best.
15:40karolherbst: tnt: well.. all I can say that the compute-runtime _has to_ respect the modifier
15:40karolherbst: otherwise it's a compute-runtime bug
15:41tnt: I know. That's why it's on their github and not mesa's :P
15:41tnt: my concern ATM is not even that, it's that something that in my understanding shouldn't work ... works. Meaning either reality is wrong, or my understanding is ...
15:41karolherbst: I see
15:42sima: tnt, blind look as in with tile64 mesa and compute-runtime just happen to pick the same
15:42tnt: And I was wondering if there was somehow / somehwere something already in the codebase that would end up converting Tile64 to Linear when exported.
15:42sima: as an explanation?
15:43tnt: sima: The thing is there is no modifier to Tile64 so it should assert : https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/drivers/iris/iris_resource.c?ref_type=heads#L1732
15:44karolherbst: tnt: why would iris ever query that part?
15:44karolherbst: that's only relevant on import afaik
15:44tnt: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/drivers/iris/iris_resource.c?ref_type=heads#L1815
15:44tnt: iris_resource_get_handle calls that
15:45karolherbst: ohh, I see
15:45karolherbst: maybe the `res->mod_info` path is hit?
15:46karolherbst: not really sure when that's set though
15:46tnt: Mmm, yeah good point. Although I'm not sure what it'd be filled with sine as dj-death pointed out, there is no modifier defined for Tile64 ...
15:46karolherbst: iris_resource_configure_main apparently
15:47dj-death: my guess is that it's not going through that path
15:47dj-death: iris_resource_get_handle() instead?
15:47dj-death: and completely skipping modifier
15:48karolherbst: anyway, gdb would answer those questions
15:48karolherbst: or give the user some patch with a ton of `printfs`
15:49tnt: Yeah, although convincing a user to spend a lot of time to debug why it works when it shouldn't might be a tough sell, they might just go away, happy it works and not caring why :P
15:49karolherbst: tnt: .... or the user has a release build, asserts disabled and modifiers == 0
15:49karolherbst: mhh
15:49karolherbst: actually
15:49sima: we don't even have a modifier allocated in drm_fourcc.h for tile64 ...
15:49karolherbst: modifier should be some garbage value
15:50tnt: Oh ... some gargbage value would work !
15:50karolherbst: yeah soo..
15:50karolherbst: `uint64_t modifier;`
15:50karolherbst: iris_resource_get_param(... &modifier);
15:50karolherbst: and on fail it just doesn't write to it
15:50tnt: It can't be zero because else, compute runtime would assume it's linear. But if it's anything else, then it will assume it's Tile64.
15:51tnt: So yeah, that might be it.
15:51karolherbst: :)
15:51karolherbst: sooo the user might get unlucky once or twice
15:51tnt: Thanks, my peace of mind is restored and the world makes sense again \o/
15:51karolherbst: heh
15:51karolherbst: might want to ask if they did a release build though, just to be sure
15:52tnt: Yeah, they said they'll be home in a few hours so will ping them then and see how that works out.
15:53karolherbst: but glad to hear that now compute-runtime can also run davinci resolve after we pimped the sharing extension enough 🙃
15:54karolherbst: (and you implemented it there)
15:57tnt: Did the intel arc bug with rusticl got worked out btw ?
15:57karolherbst: I have no idea
15:58tnt: I think it might have been the same as https://gitlab.freedesktop.org/mesa/mesa/-/issues/10846
15:58karolherbst: oh right, I wanted to get my hands on an Arc gpu
17:06tjaalton: should simpledrm support external displays? like displaying the password prompt on both laptop panel & hdmi with FDE
17:24karolherbst: tjaalton: not really
17:24karolherbst: it just implements drm on top of whatever the firmware provides
17:25karolherbst: which often means, yes, you need the full DRM drivers pre FDE
17:25tjaalton: oh damn
17:25tjaalton: thanks for confirming
17:25karolherbst: yeah.. it's an annoying situation, because nouveau now pushings huge firmware files 🙃
17:25karolherbst: *pushes
17:40alyssa: 9995f336e60 ("nir: add merge loop terminators optimisation") caused a single test regression on honeykrisp. This looks """fun"""
17:41alyssa: Presumably my backend compiler is only very subtly broken. Not scary or anything o.o
18:04pendingchaos: alyssa: try https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29679 ?
18:07alyssa: pendingchaos: still failing, but was worth a shot, thanks :)
18:07alyssa: test is dEQP-VK.graphicsfuzz.nested-for-loops-switch-fallthrough fwiw
18:11alyssa: tbh that commit scares me, I didn't realize it went in without review :/
18:12alyssa:genuinely doesn't think she knows enough to be able to understand that commit
18:15alyssa: commenting out the opt_loop_merge_terminators call "fixes" the test but woof.
18:15alyssa: on one hand, this cleared everybody else's VK CTS CI so presumably I'm doing something different here
18:16alyssa: on the other hand... that does not mean that commit is bug free :/
18:57lumag: mripard, how should we proceed with the drm_bridge_connector / HDMI connector? You have acked all core patches, but then there is a concern regarding the fwnode refcount.
18:58lumag: Is it ok to push patches 1-3 to drm-misc-next? Or we'd need to find a way to clean up the fwnode references first?
20:05KarenTheDorf: Hello, can I ask questions about the llvmpipe vulkan implementation here and/or can someone point me to somewhere more appropriate? Thanks.
20:06HdkR: This would be the appropriate location
20:08polymodeaterr: yeah well tests show in calculator that this formula works but bigger tests are needed, most of the hard stuff is about to go into data bank/cell selection logic for data format, and pc selection logic in execution format. might be falling off the development, family behaves bizarre as bizarre as you do, you seem to be finding the week spots, but you are not in worldwide outnumbering
20:08polymodeaterr: my lines just because my family is bunch of assholes, I have more allies you are not even better than my family who have abused me since I was kid, in terms of anything, completely raged crap you are, and such should not get invitations to stay together with human beings, Estonian men have always been strong and competitive, but they did not cause problems to me those who are inherently
20:08polymodeaterr: talented, do not abuse others alike, those were raw leftoverish suicidal people doing the damage and you are just alike those. like why such communities? I extend the question to my lines, if we could kick you out from your jobs, house and from our planet, you are so filthy trash. I have lived all my life with sanctions that apply only to me, ever since I remembered like from six years
20:08polymodeaterr: old, and it was all branched out by my family to most obnoxious people in the world, and it's not like you are outnumbering my lines, I am sure it's all gonna turn into conflict cause I am not yet incapable person despite being numbere one victim of abuse, my lines gonna start going against you more brutally than before you got kicked out from freenode.
20:12airlied: KarenTheDorf: here is appropriate
20:12KarenTheDorf: HdkR, airlied: Thanks. I'm experiencing an issue when resizing windows (wayland, specifically kwin). The width/stride seems to end up wrong and the image is corrupted. https://pasteboard.co/W6w2pSMU9pqM.png
20:15airlied: KarenTheDorf: might be best to file a gitlab issue to get the details like mesa version, desktop version
20:15airlied: zmike: ^ ring any bells
20:17zmike: oh no
20:17zmike: this looks like what Hazematman was working on
20:23KarenTheDorf: Well that probabally implies that it's not an issue with the library I'm writing :) I'll file a gitlab issue.
20:27Hazematman: If it's a recent issue, it may be caused by some of my dmabuf changes. Does it work if you use a version of mesa older than this MR https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27805
20:33KarenTheDorf: What's the easiest way to switch mesa version(s) without potentially bricking my machine? :D
20:34mattst88: build it locally, and set LD_LIBRARY_PATH/LIBGL_DRIVERS_PATH to run a particular app with your custom mesa
20:34mattst88: e.g. most people have some scripts like https://github.com/mattst88/mesa-run/ that they use
20:35mattst88: in any case, you won't brick your machine with a mesa update
20:35KarenTheDorf: Cool, I'll go build main and the before and after the linked merge request and see if anything changes.
20:35pendingchaos: https://docs.mesa3d.org/install.html#running-against-a-local-build-easy-way
20:35KarenTheDorf: It's gpu drivers, so I'm just a bit wary. But if I don't have to install them system-wide it should be fine.
20:50KarenTheDorf: Well it doesn't happen with an XWayland window, so that's nice I guess.
20:52tnt: karolherbst: fwiw, you were right. Returned modifier is garbage.
20:53karolherbst: nice