12:46 dmitryK: hi, all!
12:47 dmitryK: am I visible here? I have a question about GLX_EXT_swap_control implementation in Mesa (or some driver, I don't know yet)
12:47 pendingchaos: you're visible
12:49 dmitryK: thanks! :)
12:49 dmitryK: okay, could anyone help me with a question about GLX_EXT_swap_control, is there any way to debug it from the Mesa side? I have a feeling that the swap interwal of the surface is somehow reset to "unspecified" when I switch contexts/surfaces, is the swap interval considered to be a property of the surface or of the screen/system?
12:50 dmitryK: for some context: we have a weird bug in Krita when glXGetSwapIntervalMESA() for a surface is automatically switched back from '0' to '1', when I try to glXMakeCurrent() on a different native surface+context pair. It looks as if the context switch just resets the swap interval of the surface to default (https://bugs.kde.org/show_bug.cgi?id=516267)
13:05 dmitryK: I'm sorry, I got disconnected and had to pass through nickserver again :)
13:07 linkmauve: dmitryK, are there still any benefits to running it in Xwayland rather than natively?
13:08 dmitryK: linkmauve: well, some things are broken on Wayland right now, so we need to provide XWayland support as well
13:08 linkmauve: Do you have a list of such broken things? I might be interested in fixing them. :)
13:09 dmitryK: linkmauve: the problem does not appear in native wayland mode, it neither appears when we xcb_egl mode, only xcb_glx mode
13:09 linkmauve: I’m only interested in making native Wayland work, I don’t even run Xwayland on most of my systems.
13:10 linkmauve: dmitryK, oh, any reason to prefer GLX to EGL then?
13:10 dmitryK:goes to check that table to find out the correspondence between people and nicks...
13:10 linkmauve: Most toolkits and applications made the switch to default to EGL in the past decade.
13:10 dmitryK: linkmauve: it is the default in Qt :)
13:11 linkmauve: Maybe making Qt follow GTK in preferring EGL when available could be the fix here?
13:11 dmitryK: linkmauve: and we never actually tested egl backend (and, personally, I would prefer to move directly to wayland+egl) :)
13:11 linkmauve: For sure.
13:13 dmitryK: I just have a feeling that there is some bigger problem somewhere and what I see only a sign of that
13:13 dmitryK: the actual point of failure is here in Qt: https://invent.kde.org/dkazakov/qtbase/-/blob/krita/5.15/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp#L595
13:14 dmitryK: where it lazily compares the "requested swap interval" to the one save locally, while the host interval returned by glXGetSwapIntervalMESA() has already changed somewhere in-between
13:15 dmitryK: (this is the source of qt 5.15, but 6.8.0 has exactly the same code, btw)
13:16 MrCooper: FWIW, glXGetSwapIntervalMESA isn't part of GLX_EXT_swap_control
13:18 dmitryK: MrCooper: yes, but it doesn't matter in this particular case, I tried both
13:20 dmitryK: I tried to dig into Mesa's code, though I'm not sure that I can decrypt it correctly...
13:20 dmitryK: it seems like here the interval it set on something called "screen": https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/glx/glxcmds.c#L1679
13:21 dmitryK: can it somehow leak the interval from one context/surface to another via this call?
13:21 dmitryK: *is set
13:23 MrCooper: the GLX_MESA_swap_control spec doesn't explicitly say that the swap interval is per-drawable, which implies it's rather per-context
13:23 dmitryK: MrCooper: and GLX_EXT_swap_control?
13:23 MrCooper: too bad idr isn't around, he's listed as the contact in the spec
13:24 dmitryK: MrCooper: can it be that a mere creation of an off-screen surface in the same context resets the swap interval of the entire context?
13:24 MrCooper: GLX_EXT_swap_control says it's per-drawable
13:25 dmitryK: Qt's code uses GLX_EXT_swap_control... and it doesn't actually call it for anything other than '0'
13:25 MrCooper: (which kind of makes more sense, since glXSwapBuffers doesn't even require a current context)
13:27 MrCooper: reconciling per-context and per-drawable swap intervals could be tricky, which one should take precedence if both are modified from the default?
13:27 dmitryK: the most weird thing is that the value is reset not into something specifc, but **to the default value specified by vblank_mode**
13:28 dmitryK: if I set vblank_mode=1, then it works correctly, if I set it to vblank_mode=2, then it resets on context switch
13:28 lucaceresoli: Hello, I just ran into a conflict while applying a patch to drm-misc-fixes
13:28 lucaceresoli: I'm trying to fix it according to https://drm.pages.freedesktop.org/maintainer-tools/committer/conflict-resolution.html
13:29 lucaceresoli: I'm assuming it's the most correct procedure to follow (adapted to the branch I'm working on)
13:29 MrCooper: dmitryK: hmm, sounds like it might be related to DRI3 not keeping around state for drawables not bound to any context
13:29 MrCooper: *Mesa's DRI3 code
13:29 dmitryK: MrCooper: is there anything about the lifetime of GLX_EXT_swap_control, should it survive doneCurrent(), as per specification?
13:30 MrCooper: yeah, it's supposed to be per-drawable
13:31 dmitryK: then it looks like Qt's code is correct...
13:33 dmitryK: MrCooper: any hint where to look for this code?
13:38 cheako: This issue is tagged with `needs information` a week ago I added that information and since then I've added a lot more information, but the tag was never removed. https://gitlab.freedesktop.org/mesa/mesa/-/issues/14849 What's needed is someone from vkd3d(I noticed there is a ?state tracker? from mesa) to take a look and identify what the "specific" solution is.
13:39 MrCooper: dmitryK: not by heart I'm afraid
13:40 dmitryK: MrCooper: okay, thanks anyway...
13:45 lucaceresoli: OK, I think I have fixed the the right way, rerere should be updated for the resolution
13:49 lucaceresoli: jani: sima: first time I encounter a conflict, following the instructions I (think I) fixed it easily, thanks for the documented procedure!
13:49 sima: yay :-D
13:50 MrCooper: dmitryK: FWIW, src/glx/dri3_glx.c is the file
13:55 MrCooper: I suspect that loader_dri3_drawable_init ends up called again when a context is made current for a drawable
13:55 MrCooper: are the GLXDrawable IDs from glXCreateWindow or something else?
13:58 dmitryK: MrCooper: no, it comes form m_window = xcb_generate_id(xcb_connection()); xcb_create_window(xcb_connection(), ...)
13:59 dmitryK: MrCooper: here: https://invent.kde.org/dkazakov/qtbase/-/blob/kazakov/for-krita/6.8.0/src/plugins/platforms/xcb/qxcbwindow.cpp#L346
13:59 MrCooper: that's at least part of the problem then; since it's not a "proper" GLXDrawable but an implicit XWindow one, there's nothing where Mesa could attach the state to while it's not bound to any context
14:00 MrCooper: (other than the XID, which would be prone to leaks / reuse races)
14:00 dmitryK: and here is where the actual make current happens: https://invent.kde.org/dkazakov/qtbase/-/blob/kazakov/for-krita/6.8.0/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp#L481
14:03 MrCooper: i.e. using xcb_glx_create_window might help
14:07 dmitryK: MrCooper: this one is supposed to be created on the top of a normal xcb_create_window?
14:08 MrCooper: yes
14:08 MrCooper: FWIW, it's only available as of GLX 1.3 IIRC, generally not an issue anymore these days
14:19 dmitryK: MrCooper: do you know any examples of how to use it?
14:20 dmitryK: especially, the attributes part :)
14:22 dmitryK: MrCooper: btw, are there any other surface-attached state flags that I can lose on such switch without xcb_glx_create_window?
14:25 MrCooper: possibly
14:31 dmitryK: :)
14:36 dmitryK: MrCooper: the fbconfig and attributes arguments for xcb_glx_create_window should be exactly the same as for the context? Or they need something else, like width/height?
14:37 dmitryK: MrCooper: or I can skip them somehow?
14:54 dmitryK: hm.. do I understand it right that I cannot convert xcb_glx_fbconfig_t into GLXFBConfig back and forth?
14:55 dmitryK: MrCooper: how was it supposed to work before GLX 1.3 at all, if Mesa cannot store information about that? Or the problem is somewhere in the usage of XCB somewhere in-between?
14:56 MrCooper: this has always been an issue with implicit GLXWindows
14:57 dmitryK: MrCooper: so one was supposed to create an explicit GLXWindows over and X or XCB window, right?
14:58 MrCooper: it's preferable whenever possible, yes
14:59 dmitryK: MrCooper: do I understand it right that I cannot just convert GLXFBConfig into xcb_glx_fbconfig_t, I have to rewrite everything to use XCB versions of the context creation and attributes selection, right?
14:59 MrCooper: actually with DRI2 the swap interval was tracked in the X server, so this is issue is DRI3-specific
15:00 MrCooper: I'd assume both map to the same thing
15:01 MrCooper: it's all X protocol values at the end of the day
15:01 dmitryK: MrCooper: well, one is a pointer, and the other one is uint32_t :)
15:01 MrCooper: I see, it's not the protocol IDs then
15:03 daniels: cheako: once again, stop spamming every single day until your bug is fixed. if we had 15000 people demanding to know when someone else will fix their problem, this channel would obviously be pretty unbearable.
15:04 dmitryK: MrCooper: so, do I understand it right, in DRI2 the swap interval was managed by the X server, but in DRI3 Mesa now somehow bypasses the X server and works directly with the GPU driver, right?
15:05 MrCooper: it can't bypass the X server, the swap interval is just tracked on the client side
15:07 MrCooper: AFAICT xcb_glx_fbconfig_t is a protocol ID, whereas GLXFBConfig is struct __GLXFBConfigRec , so yeah different things
15:12 dmitryK: MrCooper: do I understand it right, Mesa just calls `loader_dri3_drawable_init` every time I try to make my surface current to create a corresponding object for the surface?
15:12 MrCooper: only if it wasn't bound to any context before
15:13 dmitryK: yes, it wasn't, qt moved to a single-context in Qt6
15:13 MrCooper: and only if it's an implicit GLXDrawable
15:13 dmitryK: yes, it is
15:14 MrCooper: GLXWindows created with glXCreateWindow / GLXPixmaps / pbuffers have persistent dri3_drawables
15:14 dmitryK: okay, thanks a lot for your help!
15:15 MrCooper: no worries
15:15 dmitryK: at least now I understand what happens here, it is only left to understand how to move forward :)
15:17 dmitryK: 1) I have a workaround that just recovers the interval on context switch; 2) I could just make EGL implementation preferred (with unknown consequences); 3) or rewrite a legacy part of Qt to use xcb_glx methods everywhere :)
15:34 cheako: daniels: I think there is a misunderstanding... I was clearly inquiring about a status flag and the procedures surrounding it. I was defiantly not demanding anything, nor was I ever under the impression that I'd be given any kind of timeline. Your comment is entirely unreasonable.
15:38 daniels: cheako: the people who will respond to the bug have already seen your comment on the bug, and they will get to it when they get to it. it's not the first time you've drowned a developer channel out with 'who is going to fix my bug?', and it's not the first time we've spoken about it. if you're wanting a bug fixed and aren't contributing to fix the bug, then you can file an issue and hope someone who will fix it, will see it.
15:39 cheako: What's wrong with asking who I should be talking too?
15:42 daniels: you have the answer: it's the issue tracker, where you've done everything you need to, and the next step is to wait for someone. EOT.
15:44 cheako: I did say that I hate opening issues, because it could be abused as a method to bury and forget about problems. The concept that I could file and issue and then hope that someone sees my contributions is exactly why I'd ask about issues I'm working on.
15:45 K900: So what you're saying is that everyone else should file issues and be forgotten about, and you should be making noise on IRC until your issues, which are special, get fixed
15:45 cheako: My issues are obviously special "to m?"
15:46 cheako: e
15:46 K900: So what you're then saying is that the person who is the loudest on IRC should get their issues fixed, and everyone else gets forgotten about
15:46 cheako: I'm saying the squeaky wheel get's the grease.
15:48 zmike: mostly the squeaky wheel gets put in a soundproof box because it's annoying tbh
15:48 K900: Because obviously that person's issues are the most special
15:48 K900: That's definitely not how things work
15:48 K900: And you've been told that before
15:49 K900: So what you're saying is that everyone else should file issues and be forgotten about, and you should be making noise on IRC until your issues, which are special, get fixed
15:49 K900: Also, you know the original squeaky wheel thing was said about a car, right? Like, a wheel is very much an integral part of the car
15:49 K900: And if it's squeaking, it gets prioritized because that keeps the car working
15:49 K900: So what you're then saying is that the person who is the loudest on IRC should get their issues fixed, and everyone else gets forgotten about
15:49 K900: If we're doing car analogies, you're less of a squeaky wheel and more of a guy handing out leaflets at a red light
15:50 K900: Because obviously that person's issues are the most special
15:50 K900: That's definitely not how things work
15:50 K900: And you've been told that before
15:54 cheako: I would just like to contribute.
15:56 K900: Filing issues is contributing, bothering people is not contributing
15:56 K900: Fixing issues in contributing, if you're willing and able to do that
15:56 cheako: What about my comment is bothering ppl?
15:56 pixelcluster: opening issues "could be abused as a method to bury and forget about problems"?
15:56 pixelcluster: by whom and why?
15:57 pixelcluster: like, if you assume the driver developers are malicious you might as well not do anything
15:58 cheako: pixelcluster: Everyone dog-piling onto me above. It seems that my open issues are an issue for them.
15:58 pixelcluster: ...what?
15:58 K900: It's not your open issues, it's the fact that you keep bumping them
15:59 pixelcluster: you had already opened the issue and received attention by the developers who handle the code that exhibits the issue
15:59 pixelcluster: how is it supposed to be buried by people talking on IRC
15:59 cheako: What's wrong with asking what the next steps are? You can call it bumping, but I call it asking about the new status.
16:00 pixelcluster: cheako: the main gripe i have with the idea that "the squeaky wheel gets the grease" is that you are not to decide which wheel gets grease when
16:00 pixelcluster: put harshly, you assume decisions about developer priorities and schedules that are not yours to make
16:01 pixelcluster: it's fine to ask again if there is reasonable suspicion that an issue fell through the cracks, that does happen
16:01 cheako: Correct, but I make the squeak. and asking about an issue is not anything close to making a demand of some kind.
16:02 cheako: Again, what's wrong with asking about "next steps" and "who's code is this"
16:02 pixelcluster: i mean, you do demand attention by asking for status updates and so on
16:03 cheako: Where have I ever asked about a status update? I never assume someone is working my issues.
16:04 cheako: I also am not demanding attention, I fully expect to be ignored.
16:04 pixelcluster: what you call the specific thing you asked about for your issue is besides the point here, isn't it
16:04 cheako: Even having this discussion it wouldn't be unreasonable for me to be devoiced.
16:05 pixelcluster: what do you expect others to do with the message you wrote?
16:05 pixelcluster: if you expect them to ignore it, you could save yourself the effort of writing the message, couldn't you
16:05 cheako: What I expect and what I demand are different, where is the goal post?
16:06 cheako: I expect to be told how to remove the needs information tag.
16:06 pixelcluster: my point would eventually come around to being that there is an implicit demand associated with continuously asking
16:07 pixelcluster: well, you can't remove the "needs information" tag yourself
16:07 cheako: That would be a misunderstanding, I don't assume my inquiries won't be ignored.
16:08 pixelcluster: at the end of the day you want them to not be ignored though, right?
16:08 pixelcluster: that's what is meant by "demanding" here
16:09 cheako: I expect them, not demand them... the issue you all had was with my non-existent demands.
16:09 pixelcluster: you didn't literally write "I demand someone look at this", but this is what your message effectively comes down to saying
16:09 pixelcluster: you can demand something without assuming the demands will be met
16:09 cheako: and with me wanting to work on the issues that effect me, instead of everyone elses' issue.
16:10 pixelcluster: most of this discussion seems to boil down to being pedantic about what is and isn't a "demand"
16:10 cheako: no, asking about something is an expectation... not a demand.
16:10 pixelcluster: that depends
16:10 cheako: I expec t an answer, but I'm not forcing someone to answer.
16:11 pixelcluster: forcing someone to answer goes beyond demanding
16:11 pixelcluster: if you ask something and expect an answer, that more or less *is* demanding an answer
16:12 cheako: you can feel that way, but you'd be misunderstanding me.
16:13 pixelcluster: the misunderstanding seems to be with how you understood the word "demand" to be used
16:13 pixelcluster: which I hoped to clarify
16:14 cheako: Do I need to understand why it's wrong to ask "What are the next steps?" or "Who would I ask about this?"
16:14 pixelcluster: I mean I'd hope you understand it, because then it might not be a problem in the future
16:15 cheako: Then explain that too me, not in terms of actions I never took.
16:15 cheako: I sincerely don't think it's wrong to ask about thoes.
16:16 pixelcluster: I can explain it in a query outside of this channel perhaps, to not hog this channel too much
16:18 pixelcluster: concluding the conversation on here, it'd be cool if you could accept and respect that asking it too often is wrong, even if I ultimately won't be able to convince you/help you understand
16:23 daniels: (sorry for all the noise ...)
16:24 alyssa: do we have a pass that can CSE ballot(true) within a block?
16:24 alyssa: (assuming the block doesn't contain any demote)
16:27 jenatali: Is demote not considered the end of a block? If it was then it would be trivial to CSE that, no?
16:34 alyssa: jenatali: I.. don't remember the hairy details
16:35 alyssa: but regardless not sure we have a pass even for the easy case
16:38 jenatali: Ah CSE generally allows picking a dominator's definition, I see
16:39 jenatali: Could probably update nir_opt_cse_impl to pass a more complicated predicate that allows dominators if can_reorder, otherwise requires the same block
16:41 mareko: the instr set used by CSE needs to recognize both ballot operations as equal if they are in the same block, and CSE just uses the instr set, so this would just be a change to the instr set equal function, not a NIR pass chnage
16:41 jenatali: Eh no that doesn't work for memory ops since they'd need to take into account intervening loads and stores
16:42 jenatali: But still, seems you could special-case subgroup ops as needing the same block in that predicate
16:44 mareko: one thing that should be taken into account is whether a block contains demote or terminate, which could be tracked as NIR metadata
16:44 jenatali: Terminate should be a block ender, right?
16:44 jenatali: I'd expect demote would too but I can see how that might not be
16:46 alyssa: jenatali: we allow terminate_if wherever
16:46 jenatali: Ah
16:46 alyssa: which is.. problematic
16:46 alyssa: but it's problematic both ways.
16:46 mareko: terminate reduces the number of subgroup invocations, but not necessarily to 0; demote promotes them to helper invocations, but if a quad (derivative group) is completely demoted, the implementation is allowed to terminate it
16:47 jenatali: Why is it problematic the other way?
16:47 alyssa: because control flow hampers scheduling etc
16:48 alyssa: so treating discards as intrinsics (not control flow) can be helpful
16:48 alyssa: there's prior art both ways in Intel compilers and both ways are bad (:
16:48 jenatali: Right, makes sense
16:48 jenatali: I've been hacking on WARP which treats it as flow control so that's probably where my confusion came from :P
16:48 alyssa: that's probably the... *correct* thing to do
16:49 alyssa: It's just very convenient to do the incorrect thing sometimes ;)
16:49 jenatali: Trying to remember if DXIL does... hmmm
16:49 jenatali: Nope, it doesn't
16:59 glehmann: alyssa: I don't think we have a pass like that
16:59 glehmann: but aco probably does it in the backend
17:14 alyssa: would be good to get in common, every backend wants it
17:21 glehmann: there are a few things in that area I would like to do, like constant folding ballot(true) when we know all invocations or a known subset are active, folding ballot(inverse_ballot()) if possible, flagging reductions when all invocations are active so we can emit a more optimal lowering, things like that
17:21 glehmann: but any subgroup stuff is always low prio because it's rare
17:23 alyssa: Yeah, that's fair
17:24 alyssa: I admit I was looking at a CTS test just now and not a real shader ;)
17:45 alyssa: glehmann: actually I guess if your backend has to insert uniformizes itself, you want to do this in backend anyway..
17:45 alyssa: (You /could/ insert uniformize in NIR but then you have to rerun divergence analysis with CSE in the middle and that just sounds like a mess.)