01:19 pcercuei: Can I add a Fixes: / Cc stable to a patch when I apply it to drm-misc-fixes, or should this really figure in an email?
01:52 mareko: what's the nir opcode for creating a vector from scalars?
01:53 imirkin: i think it's just nir_op_vecN
01:54 mareko: is it normal that the nir vectorizer vectorizer sources that are already vectors, but doesn't work with sources that are scalar? (i.e. it doesn't create new vectors)
06:23 jekstrand: mareko: The NIR vectorizer isn't incredibly smart.
06:24 jekstrand: mareko: That said, if it creates a vector of a vector, copy-prop should drop the 2nd level of vecN for you.
08:17 Venemo: which vectorizer do you mean? nir_opt_vectorize, or the load-store vectorizer?
08:28 MrCooper: dj-death: just need a time machine to go back and invent dma-buf at the beginning of KMS ;)
08:40 dj-death: MrCooper: I don't even know which one predates the other ;)
08:40 dj-death: kernel too old for KCMP is < 3.5
08:40 dj-death: I think we can assume we don't care
08:48 MrCooper: I've seen a few people hit the amdgpu warning because they didn't enable it in their self-built kernels
10:50 mareko: jekstrand: it doesn't create vectors at all, it only vectorizes existing vector sources
10:51 mareko: jekstrand: meaning that if sources are vectors, e.g. add input.x, input2.x; add input.y, input2.y --> the vectorizer can merge them
10:51 mareko: jekstrand: other than that, the vectorizer doesn't do anything
11:15 mareko: jekstrand: if inputs are already vectorized, then the vectorizer can vectorize operations on them
11:16 mareko: but if a user uses vec2(scalar, scalar2), the vectorizer can't do anything, because NIR lowers that
11:18 mareko: so we need a separate pass that finds and creates vectors
11:22 Vanfanel: Hi! Does it make any sense to set both DRM_MODE_PAGE_FLIP_ASYNC and DRM_MODE_PAGE_FLIP_EVENT flags in a drmModePageFlip() call? I mean: would it still send the page flip event? I am trying and it seems to send it even before I get to select on the file decriptor.
11:22 Vanfanel: It maybe it does not send it at all..
11:23 Vanfanel: That is why I dont know if both flags at the same time would make any sense.
11:45 tzimmermann: sravn, you're doing an amazing job with reviewing all these patches. thank you
12:10 mareko: krh: has the mediump work been all merged?
12:19 bbrezillon: jekstrand: I see that SpvOpAtomic{Load,Store} are mapped to nir_intrinsic_{load,store}_xxx. Should we create atomic version of those NIR intructions or just add a memory-semantics property to the non-atomic ones?
12:20 MrCooper: Vanfanel: yes, it makes sense
12:20 MrCooper: without DRM_MODE_PAGE_FLIP_EVENT, you don't get an event, so you don't know when the flip is done and you can submit the next one
12:24 pq: Vanfanel, what do you mean "appears to send" the event? Surely you actually call drmHandleEvent() to see what kind of event you got?
12:24 Vanfanel: MrCooper: But if I do DRM_MODE_PAGE_FLIP_ASYNC without DRM_MODE_PAGE_FLIP_EVENT, since I dont know when the flip has completed, drmModePageFlip() could be called before the flip has completed and return EBUSY, right?
12:25 MrCooper: that's what I just wrote?
12:25 pq: Vanfanel, if you don't even read() the DRM fd, it will remain readable forever. drmHandlEvent() reads it for you.
12:26 Vanfanel: MrCooper: yes, yes, but I wrote it in the sense of: "...but calling drmModePageFlip() twice without confirmation of the first issued flip will cause the EBUSY error, right?".
12:26 pq: OTOH, async flips probably do complete quite fast
12:27 Vanfanel: pq: that is the problem, asyn flips complete SO fast that they complete before I can check...
12:27 Vanfanel: Or at least that is what I understand that is happening
12:27 pq: Vanfanel, right, so you can't test that your code is correct, because the problem case would never manifest? :-)
12:28 Vanfanel: pq: well, not quite that. There is the problem that with ASYNC flips, my poll() call on the FD never returns. So the problem DOES manifest :D
12:28 MrCooper: test that without DRM_MODE_PAGE_FLIP_ASYNC then, it has no impact on the event processing
12:29 MrCooper: Vanfanel: DRM_CAP_ASYNC_PAGE_FLIP is advertised, and drmModePageFlip returns 0?
12:29 Vanfanel: pq: but I seem to be missing something because, if I issue an ASYNC flip and it is done before getting to the poll() on the FD, the FD should be readable anyway... Maybe I am mistaken on how poll/select work.
12:30 Vanfanel: MrCooper: Both yes
12:30 pq: Vanfanel, ok, so that works, assuming you didn't also ask for events. Always ask for events, otherwise you won't get them.
12:31 Vanfanel: pq: Lets say I issue a flip and its done before I get to the poll()/select() on the FD: would poll/select return immediately or would it never return? (I am seeing the second, but I am trying to understand why)
12:32 Vanfanel: I mean: if the event is produced BEFORE I get to the poll/select on the FD, what would poll/select do?
12:32 pq: poll would return readable immediately, *if* you also asked for an event
12:32 Vanfanel: pq: yes, that is always considering I asked to an event, of course
12:33 pq: like MrCooper asked, did drmModePageFlip call succeed in the first place?
12:34 MrCooper: Vanfanel: poll/select return immediately if the FD is already readable
12:35 Vanfanel: pq: Yes, drmModePageFlip() returns zero, that is for sure.
12:35 pq: Maybe you found a kernel bug! :-)
12:37 Vanfanel: pq: I am inclined to think that its something I still dont understand well... :D Humble and realistic
12:38 pq: Vanfanel, does it run fine and like you'd expect, if you simply drop the ASYNC flag?
12:47 Vanfanel: pq: Yes. I believe it is happening because I did not call drmModeSetCrtc() before issuing the first ASYNC flip.. I am trying to do a SetCrtc call at init, to see if things start working as expected.
12:48 pq: if drmModeSetCrtc was needed, then drmModePageFlip should have returned failure
12:49 Vanfanel: pq: that is my understanding too, but I have to try and see anyway :)
12:49 pq: Vanfanel, maybe there is a kernel bug related to ASYNC handling. It's not a usual thing to be used.
13:23 pendingchaos: cmarcelo, jekstrand: is how spirv->nir splits barriers off from memory operations correct: https://pastebin.com/raw/pDZVRPTD ?
13:24 pendingchaos: don't we need some way of preventing the operation from being moved around it's own barriers?
13:49 cmarcelo: pendingchaos: I think at the time scoped barrier was added I looked at the available optimizations that used ACQUIRE and RELEASE explicitly and made sure they wouldn't break in that case. see commit message for 73572abc2a7 ("nir: Add scoped_memory_barrier intrinsic")
13:52 cmarcelo: arbitrary reorder optimizations would just look at the presence of the barrier and bail. if the optimization looked for acquire/release, it would be careful to not mess this. ideally we would want to keep the memory semantics associated with the operations for longer, that would avoid the need of being careful in the otpimizations.
13:52 cmarcelo: pendingchaos: are you seeing this case in a shader?
14:03 pendingchaos: various message_passing cts tests
14:03 pendingchaos: I'm trying to do some ACO work for memory_model, but the scheduler and wait insertion passes are breaking the tests
14:04 pendingchaos: but the passes are respecting the barriers afaict
14:04 pendingchaos: so the NIR is incorrect but it isn't an issue with current NIR passes?
14:05 cmarcelo: pendingchaos: could be a pass that wasn't considered at the time. can you use NIR_PRINT=1 when running one of the tests to identify which pass is making the wrong transformation?
14:06 pendingchaos: it's ACO that's doing the transformations that's breaking the tests
14:06 cmarcelo: pendingchaos: right, but is it using ACO-specific NIR passes, or alredy trasnformed into something else?
14:07 cmarcelo: (another useful test but not directly realted: change spirv_to_nir to emit an ACQ_REL barrier before and after)
14:07 pendingchaos: it's passes on ACO IR
14:09 jekstrand: bbrezillon: Yes, we probably need atomic_load and atomic_store
14:09 cmarcelo: ok. not sure what you mean with "NIR is incorrect". it seems you need this information more explicitly at the time of ACO translation, so doing the split in NIR is the problem here.
14:09 jekstrand: bbrezillon: They're the same on our hardware but that doesn't mean they're the same everywhere.
14:10 cmarcelo: pendingchaos: and propagating that information (for a late lowering) seems what bbrezillon is trying to accomplish...? (haven't followed their full discussion)
14:11 cmarcelo: (for late "splitting" I mean)
14:12 pendingchaos: the NIR is incorrect because it's not equivalent to the SPIRV unless you consider acquire/release barriers to be both acquire and release barriers
14:14 cmarcelo: pendingchaos: I see. yes, that was a limitation of doing the split that early.
14:16 cmarcelo: pendingchaos: at the time we were doing only few optimizations in NIR that considered this fine grained distinction, and they were safe. and for backend Intel is way less granular, so did not matter.
14:22 cmarcelo: pendingchaos: while we dont having memory semantic for operations, we might need to make the split code (or around) be more aggressive with before/after barrier if it is not using scoped_barrier.
14:22 cmarcelo: bbrezillon: how far is the work to get those memory semantics into the operations?
14:23 bbrezillon: cmarcelo: I can push what I have
14:23 bbrezillon: it's completely untested though
14:23 cmarcelo: bbrezillon: I can wait for a proper MR, just trying to figure out if you were past exploration phase :)
14:31 bbrezillon: cmarcelo: there's this one I intend to post soon https://gitlab.freedesktop.org/kusma/mesa/-/merge_requests/27/diffs?commit_id=01c994c8a6fe5992d44945a18f1c3162f555d7d9
14:32 bbrezillon: (not directly related to the atomic-ops semantics stuff)
14:33 bbrezillon: we basically need an intrinsic grouping control+memory barriers because DXIL can't emit a control barrier without a memory barrier
14:35 bbrezillon: since you mentioned you added support for scoped_memory barriers, you might be right person to review that one :)
14:37 cmarcelo: bbrezillon: do we need to map this to a single barrier, instead of just making a control and a memory?
14:38 bbrezillon: cmarcelo: that means I'll have to add an optimization pass
14:38 bbrezillon: to group them back
14:39 bbrezillon: it seems easier to create single intrinsic from the SPIRV representation
14:40 bbrezillon: (see https://gitlab.freedesktop.org/kusma/mesa/-/merge_requests/27/diffs?commit_id=6f7da3e2e6bf365d18ceb2d6f8f65f8eae78bb32 and https://gitlab.freedesktop.org/kusma/mesa/-/merge_requests/27/diffs?commit_id=97b2e6beb7bdbfa65a70a93c3ee7802181a025ef)
14:43 bbrezillon: If I had to choose, I'd prefer always creating those control_memory barriers and adding a lowering pass for those who need them to be split
14:44 Vanfanel: pq: I found the problem. I was using SDL_LogError() to print non-zero returns from drmModePageFlip(), but for some reason SDL_LogError() does not print anything. Using SDL_Log() instead shows that drmModePageFlip() returns -22 if I set the ASYNC flag.
14:45 pq: Vanfanel, haha, nice
14:45 bbrezillon: because I'm not sure we can trivially determine that 2 separate memory and control barriers can be merged
14:46 cmarcelo: bbrezillon: sounds ok, but we need to make sure anywhere that considers memory barriers should also look for the memory semnatics in the new control barrier (or the atomic ops).
14:46 karolherbst: we could also lower it for everything except some spirv_option is set
14:47 Vanfanel: pq: Thanks for your help :) And also MrCooper of course
14:47 bbrezillon: karolherbst: that's what I did
14:47 Vanfanel: No ASYNC flips for me it seems :D
14:47 bbrezillon: cmarcelo: yep, I found a few places where it was missing while going through atomic-ops :)
14:48 bbrezillon: karolherbst: https://gitlab.freedesktop.org/kusma/mesa/-/merge_requests/27/diffs?commit_id=97b2e6beb7bdbfa65a70a93c3ee7802181a025ef#434605cbaf67bb6a29fd72426f207a4baef2ec78_2945_2948
14:48 karolherbst: bbrezillon: ohh when you look into local memory
14:49 karolherbst: bbrezillon: does DXIL support atomics on local mem?
14:51 cmarcelo: bbrezillon: other equivalent approach would be adding the "control" semantics to scoped_barrier (and perhaps dropping "memory" from its name).
14:51 cmarcelo: (which is mostly equivalent to the control_memory_scoepd_barrier)
14:52 MrCooper: Vanfanel: can't get it to work? Which GPU & driver is this?
14:57 Vanfanel: MrCooper: Intel Corporation Device 5a85, which acording to wikipedia is HD Graphics 500. I believe it uses i965 libdrm. And MESA for GLES.
15:00 jekstrand: Vanfanel: We've got async flips in the pipeline for most newer hardware but it's still working its way through review AFAIK.
15:02 bbrezillon: karolherbst: yep
15:02 bbrezillon: cmarcelo: makes sense
15:05 Vanfanel: jekstrand: thanks, that would explain it. I thought the feature was being adevertised... but then again I could be wrong.
15:05 jekstrand: Vanfanel: No, we've never advertised async flips AFAIK
15:05 jekstrand: Hopefully soon though!
15:06 Vanfanel: jekstrand: Dont worry. I will look for a solution in the meantime anyway :)
15:06 MrCooper: jekstrand: they say DRM_CAP_ASYNC_PAGE_FLIP is advertised, and drmModePageFlip with DRM_MODE_PAGE_FLIP_ASYNC returns 0
15:06 MrCooper: (but never sends out the completion event)
15:07 Vanfanel: MrCooper: in the end, it was not returning 0. Sorry about that. It was a problem with the function I was using for logging.
15:07 Vanfanel: My fault.
15:07 MrCooper: ah, that wasn't clear
15:08 MrCooper: so is DRM_CAP_ASYNC_PAGE_FLIP advertised or not?
15:09 bbrezillon: cmarcelo: hm, actually those are 2 different instructions in SPIRV
15:10 bbrezillon: and I'd need a way to say "no-control barrier" if we do that
15:13 Vanfanel: MrCooper: no. I was using a function for printig to console on non-zero returns, but it does not work as I expected, so: its not advertised and ASYNC flip issues return -22, not zero. Sorry again.
15:13 Vanfanel: Sometimes everything that could go wrong goes wrong
15:18 macc24: where can i find documentation about writing vulkan gallium driver?
15:19 cmarcelo: bbrezillon: we'd have a "NONE" scope or something to indicate it hasn't control behavior.
15:23 bbrezillon: cmarcelo: ok, I was considering adding a barrier type
15:27 sravn: tzimmermann: thnx, feedback appreciated
15:38 jekstrand: macc24: src/gallium/drivers/zink
15:50 bnieuwenhuizen: or do you mean vallium?
15:51 macc24: oh god, gallium does no vulkan
15:54 karolherbst: macc24: well, it does with vallium
15:59 cmarcelo: bbrezillon: on a second thought, if you have something already for atomic ops, I'd like to take a look at the branch. ultimately I want to get rid of the split that happens in spirv.
16:02 bbrezillon: cmarcelo: it's not properly split https://gitlab.freedesktop.org/bbrezillon/mesa/-/commits/ms/cl-atomic-ops
16:02 bbrezillon: everything is mixed up in the "tmp" commit :)
16:17 cmarcelo: bbrezillon: tks
16:22 cmarcelo: bbrezillon: I think at this point you can stop calling vtn_split_barrier for the atomics.
16:25 cmarcelo: for Intel we might want to perform the split at a later stage for our backend (or tweak the backend to consume the atomics having the semantics).
16:25 pcercuei: I have both a LCD panel and a HDMI chip connected to the exact same data pins of my SoC
16:25 pcercuei: How should I represent that? One encoder and two bridges/connectors?
17:02 pcercuei: I only need to make sure that they cannot be enabled at the same time (unless they have a compatible mode)
17:03 pcercuei: because right now it's trying to display 720p on a 240p panel, that's not pretty
17:23 shadeslayer: Hi, I'm trying to add some features to panfrost but hit this link error : /home/rockpi/Collabora/src/mesa/build/../src/panfrost/encoder/pan_bo.c:284: undefined reference to `util_set_buffer_label'
17:23 shadeslayer: I tried adding link_with: libgallium to the libpanfrost_encoder target, but it doesn't seem to do anything
17:33 shadeslayer: well, when I add libgallium to link_with, meson claims it knows nothing about that target
17:35 krh: mareko: yup, it's merged and turned on in CI for freedreno
17:36 Kayden: there is no set_buffer_label in master ...
17:38 shadeslayer: Kayden: yes, that is a local modification
17:38 shadeslayer: let me push my branch
17:40 shadeslayer: Kayden: https://gitlab.freedesktop.org/shadeslayer/mesa/-/tree/panfrost/bo-label
17:41 sravn: pcercuei: Try to get the attention of pinchartl, he is the expert in this area
17:46 Kayden: shadeslayer: why not add u_debug_label.c's contents to src/util/u_drm.h instead?
17:46 shadeslayer: Kayden: that sounds like a great idea
17:47 shadeslayer: Kayden: but I'd still have the linking error
17:47 Kayden: since stuff in src/panfrost should be using util already, but not gallium
17:47 Kayden: well, it wouldn't be in gallium/auxiliary anymore, so you probably wouldn't have to link against that
17:47 Kayden: with functions that simple you could also just make them static inlines in the header
17:47 Kayden: since they just call libdrm anyway
17:48 shadeslayer: hm
17:52 dcbaker: mareko, pepp: I had to do some work to get "radeonsi: unify and align down the max SSBO/TBO/UBO buffer binding size" to apply to 20.0, could one of you look at it and tell me if what I did looks okay?
17:54 dcbaker: you also had a patch "revert an accidental change in si_clear_buffer", which doesn't apply to 20.0, and I don't think it's necessary, but if you could confirm for me
17:59 shadeslayer: Kayden: thanks!!
18:00 Kayden: sure!
18:02 dcbaker: bnieuwenhuizen: I'm trying to apply "winsys/amdgpu: Retrieve WC flags from imported buffers." to the stagnig/20.0 branch and having some trouble getting it to apply, apart from the whitespace changes
18:03 dcbaker: pendingchaos: I'm having some trouble getting "aco: consider blocks unreachable if they are in the logical cfg" to apply to the 20.0 staging branch
18:03 Kayden: 5 things that didn't apply, sounds like a fun morning :(
18:04 dcbaker: some of them have been sitting on the branch a while :/
18:05 dcbaker: also, we're just getting to the end of the release cycle, so more and more stuff doesn't apply
18:08 pendingchaos: dcbaker: should I create a MR with a backport?
18:08 dcbaker: pendingchaos: that would be great if you could
18:15 pepp: dcbaker: for the 2nd patch, it's necessary (the change needed is: replace "<= GFX9" by "<= GFX8" here https://gitlab.freedesktop.org/mesa/mesa/-/blob/staging/20.0/src/gallium/drivers/radeonsi/si_compute_blit.c#L324). I can open a MR tomorrow if you prefer
18:16 tlwoerner: melissawen: congrats!!
18:17 tlwoerner: siqueira_: ^
18:19 melissawen: tlwoerner, thanks!! I'm very excited about this project!
18:19 tlwoerner: i just received an email from google saying that melissawen will be doing GSoC 2020 with XOrg :-)
18:19 dcbaker: pepp: if you could open the MR tomorrow I'd appreciate it
18:19 imirkin: which project got approved?
18:20 tlwoerner: imirkin: Improve VKMS using IGT GPU Tools
18:20 imirkin: [for those not following along]
18:20 imirkin: ah cool
18:20 pepp: dcbaker: will do
18:20 dcbaker: thanks
18:20 tlwoerner: siqueira_ is the mentor
18:20 arora: Hey jekstrand, it's been a long time, umm sadly my GSoC application got rejected. Since that dual GPU project was close to my heart, can I work on it in my part time?
18:20 imirkin: nice
18:20 tlwoerner: others are welcome to help mentor too ;-)
18:20 imirkin: hehe
18:22 pendingchaos: dschuermann, dcbaker: backport of "aco: consider blocks unreachable if they are in the logical cfg": https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4888
18:24 tlwoerner: arora: i don't see why not, it would be great to see some progress on that project too. then next year you could apply again :-)
18:28 arora: tlwoerner: oh ok I will start working on it soon. hopefully I will make it next year ;D
18:29 arora: tlwoerner: were any other xorg projects selected as well?
18:29 tlwoerner: arora: no, just the one
19:12 jekstrand: arekm: Absolutely.
19:12 jekstrand: arora, rather
19:18 bbrezillon: cmarcelo: ok
19:18 bbrezillon: cmarcelo: I'll keep you updated
20:08 sravn: narmstrong: chrontel-ch7033 looks good to go in, I did not find anything when browsing the code
20:10 sravn: narmstrong: is Andrzej Hajda on irc? If yes, what is hes nick?
20:14 mareko: dcbaker: the first one looks ok, the second one is not necessary, though I guess it just doesn't apply because of the indent changes
20:16 narmstrong: sravn: looks good to me aswell
20:16 narmstrong: sravn: I’ll add r-b tomorrow
20:16 narmstrong: sravn: afaik no he isn’t on irc
20:40 alyssa:mumbles about use lists
20:41 alyssa: list_is_empty(&dest->ssa.if_uses) is false even though there's no branching whatsoever here
20:42 Kayden: did you check dest->is_ssa first?
20:42 alyssa: aye
20:42 Kayden: that seems really bad then
20:43 alyssa: oops? :p
20:43 Kayden: we may have missed handling it in one spot
20:44 Kayden: I've fixed some bugs like that in the past, but haven't seen any in a while
20:44 alyssa: down the rabbit hole..
20:44 alyssa: (for dest mod handling)
20:46 anholt: do you have nir validate enabled? it's supposed to catch that
20:48 alyssa: I thought so? It's a debug build
20:49 alyssa: further down the hole we go, nir_foreach_use hang..
20:50 alyssa: Maybe my backend is somewhere clobbering something
20:53 alyssa: validating fine, I must be doing something silly
20:54 Kayden: could throw validate passes throughout the backend
20:55 alyssa: I'm not supposed to be mutating the nir at all in the backend though :>
20:57 alyssa: valgrind seems mostly happy
21:01 alyssa: OK, someting definitely smelling funny on my end (not NIRs)
21:03 alyssa: Ohhhhhh, right, forgot -- argh. Okay. Rewriitng all my code.
21:03 alyssa: Thanks.
21:04 alyssa: (For future denizens: don't shallow copy list_head or things will break very very bad)
21:05 pcercuei: sravn: thanks
21:05 pcercuei: pinchartl: hello :)
21:10 dcbaker: mareko: cool, thanks