00:31karolherbst: zmike: okay.. got intensity working, but what's the issue with 2d buffer there?
00:34zmike: you can't swizzle a bufferview in vulkan
00:34zmike: I've been considering whether I could reuse the 2dimport path for it
00:37karolherbst: zmike: okay sure, but we don't use buffer views for 2D from buffer in the first place
00:38zmike: I said buffer views
00:38zmike: not 2d buffer
00:39karolherbst: mhh okay, but it's not working for 2d buffer either
00:40zmike: could be the same issue
00:40zmike: I assume it's related to the swizzling
00:41karolherbst: yeah, and it's all RRRR
00:41karolherbst: I don't think it's the swizzle
00:41karolherbst: it's just returning 0 for some values
00:41karolherbst: maybe something with strides or something silly
00:42karolherbst: anyway.. I'm not concerned about 1dbuffer, because rusticl calls is_format_supported with PIPE_BUFFER for those, and zink hopefully just doesn't return intensity there
00:43karolherbst: well.. zink doesn't prevent that...
00:43karolherbst: I should fix that
00:48zmike: is it actually applying the swizzle?
00:49karolherbst: I would expect that if that would be the issue, the test would fail in a different way
00:49karolherbst: but the vulkan side image view did have a RRRR swizzle
00:49karolherbst: or at least zink did create such one
00:50zmike: that's something
00:50karolherbst: mhhh lvp crashes
00:51zmike: can lavapipe actually do the 2d buffer import normally?
00:51karolherbst: also crashes with non intensity formats...
00:52zmike: I'd be surprised if lavapipe could do the dmabuf reinterpret
00:53karolherbst: let me make the CTS be a bit more verbose... it's always hard to figure out what actually goes wrong
01:02karolherbst: mhh yeah okay.. all reads are just 0
01:11karolherbst: I'll take a look tomorrow, it seems like this failure is another regressions or unrelated or something
01:15karolherbst: yeah....
01:15karolherbst: it's also broken for non intensity, but at least that's a regression
01:22karolherbst: ah no.. it was a local patch of mine, but.. mhhh weird...
01:22karolherbst: mhhhh
01:24karolherbst: ah no.. I just uhm... I'm tired :')
01:29karolherbst: okay.. it works on 25.1 branchpoint, it doens't on main.. good
01:30zmike: probably my surface refactor broke it somehow
01:31karolherbst: I have the feeling it's me
01:40karolherbst: zmike: okay, it's you: b022cdc8a1c3534d6f57f53b876e30b10e339432
01:42zmike: huh
01:42zmike: I guess that means there's a place that should be setting res->valid and isn't
01:42zmike: you could probably find it pretty trivially by seeing where the resource is written before that call
01:44karolherbst: mhh with that worked around.. CL_INTENSITY 2d_from_buffer does work for read_image (which is a texture read), it works for write_image (guess the shader simply ignores the other components), but for read_write images it doesn't, because the read is an actual image_read operation and as I said.. no swizzles for those
01:44karolherbst: right...
01:44karolherbst: I'll figure out a proper patch tomorrow
01:45karolherbst: just need to figure out what to do about those image views...
01:45karolherbst: might be easier if zink just sets the swizzle 🙃
01:46zmike: feels like cheating if I do all the work for you
01:46karolherbst: yeah but other drivers also handle it internally :P
01:46zmike: I guess
01:46karolherbst: or do you want to have a swizzle added to pipe_image_view?
01:47zmike: I don't really want that for just this one thing, no
01:47karolherbst: okay :)
01:48zmike: smh being bullied now
01:49karolherbst: anyway, I'll send patches tomorrow or so
09:14phasta: I've got a bug fix for a new bug in the current -rc. Applying to drm-misc-fixes fails, though. What should I do about that?
09:20phasta: Ah wait, my bad. Outdated branch
09:30phasta: Still. Why is it that a bug-fix that is neither in drm-next nor drm-misc-next should be applied to drm-misc-next? I thought drm-misc-next is for new features and won't be sent to Linus after feature-freeze
10:29tzimmermann: sima, when pushing the reverts, dom told me: "dim: ERROR: a71e35aecc07 ("Revert "drm/etnaviv: Use dma_buf from GEM object instance""): Mandatory Maintainer Acked-by missing., aborting". is that intentional? looks like a bug to me. your r-b should be enough IMHO. i've now pushed with 'dim -f', but still...
10:29tzimmermann: s/dom/dim/
10:31sima: tzimmermann, hm maybe it's mripard's maintainer-ack check misfiring?
10:31sima: mripard, ^^ thoughts?
10:31sima: tzimmermann, and yeah don't see why there's anything amiss with that one
10:32tzimmermann: not problem in practice, but it looks like an oversight
10:32sima: tzimmermann, 43254c2aa575037fc031c7ac21b0d031c700b2bf in dim, just landed recently
10:32sima: yeah false-positives in checks are not good, because it trains people to ignore them
11:17mripard: sima: we've had a bunch I was looking into this morning, and I'm a bit confused for some.
11:17mripard: in this particular case, it's not a false positive
11:18mripard: drm-misc isn't the maintainer of that driver, and we have no acked-by from a maintainer
11:19sima: hm
11:19sima: well maybe airlied/me should overrule as acks, but no idea how to map that
11:19mripard: you do
11:19mripard: but you didn't give an acked-by either
11:20sima: and yeah etnaviv is a bit the odd one out, maybe should add drm-misc for them as fallback since defacto it's kinda the situation anyway?
11:20sima: lynxeye, ^^ thoughts?
11:20sima: mripard, I kinda r-b'ed, maybe should imply?
11:20sima:not sure
11:20mripard: not really
11:21sima: or maybe airlied&me should get into the business of liberally acking?
11:21sima: also doesn't feel like a job we should do, smells a bit much like lock keeper stuff we try to avoid
11:21mripard: https://docs.kernel.org/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by
11:22sima: hm yeah maybe should just print more acks for these cases for now and see ...
11:22sima: tzimmermann, ^^
11:22mripard: acked-by doesn't mean you reviewed it, just that you're ok with it being merged (possibly in a separate tree)
11:22sima: or just add some of the smaller drivers that aren't yet in drm-misc but often land through there officially as a 2nd tree
11:23mripard: and reviewed-by means that you reviewed it, but doesn't provide any opinion on how it should be merged
11:23sima: yeah I know, just means more tags but well paperwork is going to paperwork I guess
11:23mripard: maybe give both if you don't care?
11:23sima: yeah
11:23sima: plus maybe add some more things to drm-misc officially for these cases
11:23sima: make the flow more explicit can't hurt, process transparency and all that
11:23mripard: yep
11:23sima: that transparency is honestly biggest reason why I like your dim change
11:24mripard: it was going well until that week though.... we had ~10 patches triggering that warning
11:24sima: yeah I expect some surprises, always happens with this stuff
11:24mripard: and most of them were legit, where the committer obviously ignored the warning.
11:25mripard: so we also have to weigh in acceptance
11:25sima: yeah it'll take some educating to get there
11:25mripard: because if committers are just going to use dim -f all the time, it's a net loss.
11:25sima: did you reply to the patches were legit warning was ignored?
11:25sima: yup
11:26mripard: a funny source of false positive is that some have their name quoted in maintainers
11:26mripard: but git doesn't
11:27mripard: so the strings don't match, even though they are obviously equal
11:27mripard: https://gitlab.freedesktop.org/drm/xe/kernel/-/commit/73c0e8054fcf36883c1a20d5e2e91fb8ed24d3ea is such an example
11:28mripard: no, sorry, that one is a legit false positive
11:29mripard: I meant this one https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/a6cfa4c8833944f8912c1fa7f95795753f6376ea
11:30mripard: we have the acked-by from Rafael
11:30mripard: but he's listed in MAINTAINERS as '"Rafael J. Wysocki" <rafael@kernel.org>'
11:31mripard: (but not consistently, for additional fun)
11:49zmike: mareko: you probably want to weigh in on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36156
11:53sima: mripard, just matching on email and trying to canonicalize with .mailmap?
11:55mripard: yeah, that's a good idea
11:55mripard: possibly leveraging python's email module that we already use to parse the address properly
12:37lynxeye: sima: I try to give acks for the etnaviv things I think should be merged through drm-misc, but TBH haven't been quite on top of it due to too much other stuff. On the other hand people seem to assume that etnaviv goes through drm-misc and don't really look into MAINTAINERS. I actually pondered moving etnaviv to drm-misc just to adjust reality to the assumption, but haven't quite made the switch yet.
12:56sima: lynxeye, yeah was more wondering whether we should put it into both
12:56sima: main dev still through your tree, but kinda the more random things and subsystem stuff can officially go through drm-misc too
12:56sima: which I think is where defacto we are right now, roughly
12:57sima: so as long as mripard's dim check can cope with multiple git repo lines, we should be fine
12:57sima: lynxeye, that way you can make any decision about moving main etnaviv dev at your own pace, and we still document a bit more accurately what's actually going on
13:11lynxeye: sima: Yea, if the scripts can handle that, that would be fine. I have no intention to introduce interdependencies between drm-misc and the etnaviv tree for the subsystem wide changes that happen to touch etnaviv. Those should always go through drm-misc. Conflicts due to this mode of operation are few and easy to handle on my side.
14:07sima: mripard, can dim cope with that?
14:09mripard: sima: I'm not sure how we could solve this, really. Because we already have multiple git repos between drm-misc, drm and linus' iirc.
14:10mripard: the problem with etnaviv is that we're merging patches into a repo that isn't documented in MAINTAINERS
15:13sima: mripard, https://paste.debian.net/hidden/978b9ce2/ this is what I'm thinking off
15:13sima: just means dim needs to allow 2 git repos
15:13sima: or I'm not understanding the issue
16:38karolherbst: zmike: okay.. I learned new things: 1. for storage images the component remap needs to be an identity remap, so that just rules out intensity for storage images completely. 2. the zink_batch_reference_resource_rw calls inside zink_copy_buffer are causing the img2d_from_buf fails, and overriding them to assume src/dst are images is fixing the sisue
16:39emersion: hmmm, dim push-branch drm-misc-next fails with:
16:39emersion: fatal: bad object refs/remotes/drm-intel/topic/core-for-CI
16:40emersion: i've tried rm'ing the remote and running dim setup but that doesn't fix it
16:40emersion: any ideas what's up?
16:58zmike: karolherbst: 2 is actually stupider
16:58karolherbst: zmike: I've subbmited https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36200 but no idea if there are better ways :)
16:58zmike: I saw
17:01karolherbst: in regards to 1. in _theory_ I think writing to intensity images could be allowed, I just don't know if it's valid to assume that a vec4 write to the R image does what we want?
17:01zmike: no clue
17:01karolherbst: but... can't really express that in gallium anyway
17:01karolherbst: I know it worked fine on anv for writing to them, but reading from intensity storage images was showing really odd behavior
17:02karolherbst: I doubt anybody ever needs it, so whatever really
17:03zmike: my MR should fix your not-intensity issue
17:04karolherbst: quick testing tells me it does
17:04karolherbst: let me push it through my testing to confirm
17:12daniels: emersion: git remote prune drm-intel? git symbolic-ref -d remotes/intel/topic/core-for-CI?