00:00vsyrjala: was there some other client besides bichon you pointed out? only remeber that one
00:00daniels: mareko: re 'hopefully delete accidentally released confidential information' - you need to ping admins for that, but that's something we are (I am) practised in by now
00:01jenatali: Can confirm :)
00:01daniels: vsyrjala: there were a few others before that, but indeed bichon seems the most promising, so you might want to try that out at some point perhaps
00:02daniels: imirkin: btw, 'bullying' isn't at all accurate - just because everyone else prefers something different doesn't mean you're being bullied
00:02imirkin: daniels: well, it's how i view it
00:03daniels: I'm sorry you feel that way, but I don't empathise with it, any more than I would describe a GitHub newcomer turning up in Mesa 3 years ago as being 'bullied' into email workflows
00:03imirkin: slightly different ... existing workflow vs forcing everyone to switch workflows
00:04daniels: projects work one way or another, dependent on the will of its contributors - if a project is actually being bullied into workflows its contributors don't support, it will v rapidly cease to retain those contributors
00:04imirkin: i don't remember a vote being held on it or anything like that
00:04daniels: you'll remember I'm sure that MRs started off purely optional, and rapidly became a fait accompli not because of some great overbearing external force, but simply because that's where everyone* chose to be
00:04daniels: *: to within margin of error
00:05imirkin: to the point that now you get yelled at if you just push
00:05imirkin: or attempt to use the mailing list for a proper review
00:06daniels: sure, in the same way that you previously would've got yelled at if you'd pushed a MR on GitHub and expected that to get reviewed
00:06imirkin: i don't see a problem with people doing that in the "old times"
00:06imirkin: it's just that people might not have reviewed
00:07daniels: Mesa was there, it's now somewhere else; it's a mutable entity
00:07daniels: in the 'old times' there was a script to auto-close MRs telling people they needed to set up git-send-email
00:07imirkin: and i don't like where it's at. makes me much sad.
00:07daniels: sorry to hear that
00:07imirkin: at times i express this sadness.
00:08imirkin: as well as my perception of the events / actions
00:08daniels: but I would invite you to compare the initial Mesa-on-GitLab suggestions and announcements, which were extremely cautious in tone and implying a far more gradual transition, with the actual usage of both contribution pathflows
00:09imirkin: i take no issue with those announcements.
00:09imirkin: (i do remember them, at least for the most part)
00:09jekstrand: We've never had particularly formal processes for these things in Mesa. You can say "I don't remember a vote being held" but, then again, I've never seen a vote happen. Do we even have a mechanism for that?
00:09daniels: you can easily profile the preferences of the developer base from who chose to do what; from my point of view as a modern-workflow maximalist, the bell curve hit at about 20% of what I was expecting
00:10daniels: jekstrand: 'Brian says' :P
00:10jekstrand: Stuff tends to happen by consensus/momentum. Clearly, that was in favor of GitLab.
00:10imirkin: they were pretty clear, at least originally, that gitlab was just going to be the new hosting for git because of various syadmin reasons
00:10daniels: yes, that much was diktat, and implied nothing in terms of contribution
00:11imirkin: which was fine
00:11imirkin: (ultimately who cares what software / setup is hosting the git server -- it's transparent)
00:12daniels: what was up to the developers is where they chose to post their contributions, and I think the outcomes (if you profile number of ML patchsets vs. number of MRs, accounting for the disconnect between MLs often counting patchset revs as new patchsets vs. MRs not doing so) are very clear
00:12daniels: like I say, it exceeded my expectations and hopes by a substantial factor
00:12imirkin: yeah. i just think we had a really good system that worked ideally for me, and we have a system now that is none of that
00:12daniels: I'm genuinely - genuinely - sorry to hear that
00:13daniels: just as I am to hear Ville's dispirit
00:13imirkin: i suspect that for the full-time crowd it's actually better (although Ville's experience may suggest otherwise), but as a part-time contributor, just having everything in email is ideal
00:13imirkin: otherwise i have 30 places to check
00:14daniels: sure, but then other people would argue that as a part-time or occasional contributor, having to have been subscribed to a mailing list before any patchset you cared about was submitted, and to be getting new-thread notifications for every single patch posted to every single driver, is non-ideal
00:15imirkin: maybe. i would argue it's ideal (except for the subscribe-to-mail part, but that's a sad reality of the modern email world)
00:16imirkin: lets you quickly see what's going on, core, other drivers, etc
00:16imirkin: takes about 5-10s to read a patch email, just hit "j" in google to see the next one
00:16jenatali: I don't entirely buy that argument... I feel like I get emails for all the things that are relevant
00:16daniels: we're beyond rehashing old points for now, so all I'll add to conclude (because I do very much need to conclude now), is that if you believe that the move was enforced against anyone's will, you should graph ML/GL submissions against time, with whatever bias you care to apply for affliiation / part-time / etc
00:19daniels: anyway, gtg, sorry. if there's anything I can help with then lmk, but please do also either highlight or privmsg me because I'm only semi-around for the next few days
00:22imirkin: nah, it's just a bit triggering when i see messages which suggest that gitlab PR flow is the only way and no way anyone could ever like the email flow. i'm probably reaching radeonhd-guy's level of annoying by now =/
00:26HdkR: alyssa: 72% CPU time in NIR passes? Time to optimize NIR passes, or the ordering of the driver calling them? :)
01:23marex: hey, is anyone familiar with Weston internals around ?
01:24marex: daniels: you maybe ?
01:24marex: I noticed a funny behavior here ...
01:24marex: originally, I thought this was a chromium bug, but I think this has something to do with WL/Weston
01:25marex: I have two devices, both mx6q, both with display/touchscreen , one has a keyboard, the other does not (!)
01:25imirkin: probably pq --^
01:25marex: now, if I start weston and tap the "terminal" icon , I get Wayland Terminal
01:26marex: on the device WITH keyboard, the terminal has focus (the window receives XDG_TOPLEVEL_STATE_ACTIVATED I believe)
01:26marex: the terminal cursor is "filled"
01:27marex: on the device WITHOUT keyboard, the terminas has focus too, but the terminal cursor is hollow
01:27daniels: marex: this is more for #wayland, desktop-shell focus behaviour is strongly tied to keyboard, so for all that the behaviour is undesired and thus a bug, it's unsurprising. if you want to do solely full-screen apps, I recommend kiosk-shell instead
01:27marex: daniels: kiosk-shell has the same behavior ;-)
01:29daniels: marex: is that true for master as of ~5h ago? alf just pushed a fix for that today (IIRC)
01:30marex: daniels: I dont know (yet)
01:31marex: daniels: which patch is that ?
01:32alyssa: HdkR: Yeah, probably.
01:34marex: daniels: oh, e62ccf17 ("kiosk-shell: Give keyboard focus when mapping the surface")
01:34daniels: marex: yep
01:34marex: daniels: lets find out
01:35marex: daniels: thanks for the hint
01:37marex: daniels: still the same problem, so nope
01:37marex: daniels: ah, but thats for kiosk shell, errr
01:40alyssa: imirkin: Dunno if it means anything but I mostly prefer ML to gitlab
01:40marex: alyssa: +1
01:41alyssa: Though I have a hacky script to make gitlab as ML like as possible which has worked well for me
01:41imirkin: alyssa: good to know i'm not alone :)
01:42marex: because ML is simple and it does exactly what it is supposed to do, nothing more, nothing less ?
01:44marex: alyssa: I'm just debugging chromium on imx6/etnaviv, please tell me something I dont know yet
01:44imirkin: alyssa: how do you feel about webgl?
01:45robclark: It would be nice if gitlab somehow magically had a better email bridge (although I understand that is not an easy thing).. but I'll take gitlab's shortcomings over email's shortcomings (speaking as someone who has to deal with email list workflow for a kernel driver, and who is seriously wanting to switch to gitlab for kernel)
01:45alyssa: imirkin: *vomit and/or poop emoji*
01:45marex: etnaviv still seems to have problems with webgl and threaded compositing of chromium :(
01:46alyssa: robclark: I remember the worst thing with ML was downloading patches in a way that I could apply and push, I guess patchwork helps? but people able to type `lab 6666 m` and have something assigned to marge is a lot more convenient
01:46robclark: alyssa: please tell me you can at least https://playcanv.as/p/MflWvdTW/ .. otherwise that is arm trolling you ;-)
01:47imirkin: patchwork was nice for retrieval of patches so you didn't have to deal with stupid gmail's limitations on that
01:47imirkin: robclark: out of curiousity, what kind of fps do you get on that playcanvas thing?
01:48imirkin: (just want to see how sad my GP108 is...)
01:48robclark: yeah, I use patchwork for kernel stuff.. but esp when it comes to dealing with patches for new hw bringup, I tend to get patches that where tested on some other patches.. I'd like to shift the burden to applying patches on top of msm-next to the submitter..
01:48alyssa: robclark: wfm on RK3399 with 20.3
01:49imirkin: at like 1024x768 i'm getting like 15fps =/
01:49alyssa: im getting like 4 on here but old mesa, older gpu, missing opts, ..
01:50robclark: imirkin: iirc, 'after the flood' was a bit heavy.. I think the mali demo wasn't so bad.. but need to figure out a way to measure fps
01:50imirkin: alyssa: what resolution?
01:50imirkin: robclark: there's a button
01:50imirkin: the middle button that looks like the middle finger
01:50imirkin: shows you stats
01:50alyssa: imirkin: 2/3 fps
01:51alyssa: screen is 2400x1600 and subtract a chunk of Y from header bar / etc
01:51imirkin: hm, ok. let's try to match that...
01:51imirkin: i have 2400x1920 to play with :)
01:52imirkin: yeah, it's at 3fps in the stats, but actually felt like less than that
01:52marex: daniels: right, no, the patch doesn't help even on kiosk shell, but thanks for the hint, I'll keep digging around that
01:52imirkin: GP108 doesn't have reclocking, so it's running at like 1khz
02:07vsyrjala: robclark: you don't just tell them to rebase their patches? not sure how gitlab is going to help with that. aren't they just as likely just going to give you a branch based on some ancient baseline?
02:11airlied: vsyrjala: then you can git merge it
02:11alyssa: if anyone wants my hacked up mesa-only gitlab cli script, lmk
02:11airlied: if you have patches with no baseline at all you end up spending a lot of time going around the can you rebase again cycle
02:11airlied: I don't think my intel_display.c refactor patches once hit the CI without failing to apply
02:12robclark: vsyrjala: they have to push a branch against what they want to merge against
02:12airlied:would like things to hit CI then worry about rebasing them
02:12robclark: (and that is only part of it.. CI even if it is only build jobs to start to catch the stupid CONFIG_DEBUG_FS=n stuff) would be a win)
02:13vsyrjala: airlied: not sure how you managed that tbh. i guess not rebasing before sending?
02:13marex: daniels: so if I create uinput keyboard, suddenly, wayland terminal gets focus :)
02:13airlied: vsyrjala: patches got applied in between my sending and CI getting
02:14airlied: it seemed I just had bad luck in timing the races there
02:14vsyrjala: i do agree that branches make applying stuff easier. just not sure sure how that will help against ancient baselines
02:15vsyrjala: if you want to avoid being the one to do the conflict resolution that is
02:15airlied: git merge works a lot better than apply to a new baseline
02:15airlied: like a set of patches with no baseline info is impossible to apply usually
02:15airlied: I don't mind doing conflict resolution
02:16vsyrjala: i gathered that was what robclark was objecting to doing
02:16airlied: in fact we generally prefer conflict resolution to be the job of the maintainer since they are meant to be better at it
02:19vsyrjala: speaking of the intel_display.c refactoring. i just rebased an old branch across it, and sadly git was totally lost. had to format-patch+manual edit stuff to get it to at least try to apply the hunks to the right file. and even then got left with a lot of conflicts even wiggle coulnd't understand
02:19vsyrjala: but i'll admit that is not the usual case
02:31robclark: airlied: conflict resolution is one thing.. but people sending patches against last LTS product bring-up kernel kinda is annoying..
02:40airlied: robclark: yup that is much worse
02:43robclark: dealing with conflicts with other things coming in same cycle is one thing.. at least that is fresh on the mind
03:59airlied: mareko, imirkin : you (or any other GL maintainers) have any interest in things like GL_OVR_multiview2 into gallium?
04:03airlied: Kayden: ^
04:54Kayden: I don't know how useful that is, or if most things using multiview also transitioned to vulkan at this stage...I actually kinda thought we'd hooked up OVR_multiview at one point, but it seems not
04:55Kayden: I remember cmarcelo was working on multiview at one point
05:36airlied: Kayden: yeah for lvp I might want to plumb some bits of it through but not sure how much effort I should expend on the gallium interface
05:39Kayden: ahh, yeah, lavapipe
05:53cmarcelo: Kayden: airlied: yeah, I've ended up not hooking up GL, in part because other things took precedence over it.
08:38MrCooper: imirkin: it's not hard to set up GitLab e-mail notifications so you get more or less the same patch review e-mails as you would have with the e-mail based workflow
08:40MrCooper: you can also e.g. only get e-mails when MRs/issues are created/closed/merged, and then enable more notifications for individual MRs/issues of interest
09:19pq: vsyrjala, when I do Gitlab reviews, I often pull the MR branch into a local branch for inspection and git-grepping. I also leave that branch around, so that the next time I get back to the MR and it has been revised 7 times, I can compare directly what I looked at last time vs. the current.
09:32danvet: pq, gitlab leaves all the old versions around for pulling
09:32danvet: iirc $branch/$number or so
09:32danvet: so you can do range diff and all that
09:36pq: marex, if there is no keyboard, then weston has no keyboard focus to give. Maybe that explains what you see.
09:38pepp: btw gitlab has a "Viewed" button when reviewing changes which "Collapses this file (only for you) until it’s changed again.". It can be useful to only review the deltas betwen MR revisions
09:51pq: danvet, cool, I hadn't dug that far, but my way also avoids having to figure out which rev I looked last.
09:52pq: and when I say "MR branch", I mean the mr-number thing upstream, not the contributor's fork branch
09:54pq: marex, if the terminal fills in the text cursor only then it has keyboard focus, that would explain. Window being active can happen without keyboard, too.
09:54danvet: pq, yeah I thought you can pull the revisions from the mr branch
11:04Chaekyung: What, if any, application uses the Gallium Nine? Is it possible to use it with Wine, or anything else practical, or is it still some work in progress of sorts?
11:05hifi: patched wine is probably the primary use case
11:05hifi: IIRC it can give major performance gains over the D3D->OGL translation
11:08marex: pq: yes, that is what happens
11:08marex: pq: but that is also a bit strange
11:09marex: pq: wouldn't it be better to just give the focus to the window consistently, keyboard or not ?
11:09pq: marex, it's something the terminal chooses to do.
11:09pq: marex, there is no "the focus".
11:09marex: pq: chromium on weston has the same problem
11:09marex: pq: my terminology is likely off
11:10marex: pq: er ... do you have some time to discuss this ?
11:10pq: marex, the window being active is one thing. The window having pointer focus is one thing. Having keyboard focus is another thing. And touch input is again different.
11:10pq: marex, yeah, I can chat, but maybe we should take this to #wayland?
11:11marex: pq: yes
12:45imirkin: airlied: i have no objections, but i also wouldn't want to commit to it being supported by nouveau. i did add NV_viewport_array2 support, which i think can be used to similar effect though.
12:46imirkin: airlied: i guess you'd just set ViewportMask = 0x3, and then use the ViewportIndex in frag as the view id?
12:47imirkin: (and some day i'll actually follow through on the passthrough gs ext... i have it like 30% done in a branch somewhere)
14:29Prf_Jakob: So anyway I can get EGL/GBM/libdrm to not try to use the master node and instead use the render node?
14:29Prf_Jakob: At somepoint even eglinfo broke
14:31pq: you can? I mean, what's your question? :-)
14:31Prf_Jakob: Can I do that without recompiling
14:32Prf_Jakob: Can we make that the default as well?
14:32pq: GBM without a primary node is a concept I don't think I've met before. Why not use surfaceless instead?
14:33Prf_Jakob: I want that to not return llvmpipe :p
14:33Prf_Jakob: amdgpu_device_initialize: amdgpu_query_info(ACCEL_WORKING) failed (-13)
14:33Prf_Jakob: amdgpu: amdgpu_device_initialize failed.
14:33pq: no, use eglGetPlatformDisplayEXT() instead, otherwise you don't know what platform you got.
14:33Prf_Jakob: And I'm getting that on my console, so I assume that's from GBM.
14:35Prf_Jakob: And what platform should I be using?
14:35pq: that failure sounds real though, maybe your installation is broken?
14:36pq: surfaceless, but I don't think that's your problem.
14:36pq: or maybe it is... NULL might try to connect to a X11 server or a Wayland server or...
14:37emersion: pq: GBM on render node is useful to select the GPU
14:38Prf_Jakob: Reading that thread, brings me to the question. How do I get EGL/GBM/libdrm to use the render node instead
14:38pq: emersion, not EGLDevice stuff?
14:38emersion: EGLDevice broken on split render/display
14:38emersion: but otherwise would be a good choice
14:38pq: but you don't have a primary node to begin with
14:38pq: I mean, don't care about one
14:39Prf_Jakob: This is for XR we I want to be able to write applications that only uses EGL and OpenXR to get things onto the screen. Not having to teach those applications about X11 and Wayland would be a huge win.
14:40pq: Prf_Jakob, right, so, don't pass NULL to eglCreateDisplay()
14:40Prf_Jakob: What should I pass to it?
14:40Prf_Jakob: Or the other function
14:40pq: Prf_Jakob, gbm_device perhaps, one you created for a render node.
14:41Prf_Jakob: This used to work, using GBM is just as bad as using X11 and Wayland.
14:41emersion: how do you select the GPU, Prf_Jakob?
14:41emersion: "as bad"?
14:41Prf_Jakob: For 99.9999999999999999999999% of the time it just works
14:42Prf_Jakob: For the other cases you can use what env variable EGL/GBM/libdrm looks for
14:42pq: Prf_Jakob, I don't think it's possible to do what you want. EGL is not magic, it doesn't know where you want to connect to if you don't tell it.
14:42Prf_Jakob: I would like it to connect to the only GPU that is plug into my computer
14:42Prf_Jakob: (And this has worked in the past)
14:43pq: if you use EGL_DEFAULT_DISPLAY on Wayland, you get to a situation you cannot display anything.
14:43Prf_Jakob: Yes but I'm not on Wayland
14:43pq: so what are you on?
14:43emersion: what are you using EGL for?
14:43Prf_Jakob: To get OpenGL
14:43emersion: are you not using EGLSurface?
14:43Prf_Jakob: I'm using it with the OpenXR EGL extension you help write :P
14:43emersion: ok, so no need for WSI
14:44emersion: so i'd suggest just using EGLDevice
14:44emersion: plus the device platform
14:44Prf_Jakob: But you know couldn't that be the default?
14:44Prf_Jakob: Like I think that's what it's trying to to
14:44Prf_Jakob: to do
14:44pq: but you also said you want to display stuff? How does that work then?
14:44Prf_Jakob: Monado is talking to the headset
14:44emersion: pq: shares buffers with vulkan
14:45pq: vulkan? are not talking about EGL?
14:45pq: are you allocating buffers with OpenGL and exporting dmabuf from them?
14:46Prf_Jakob: We don't need Wayland or X11
14:46emersion: i don't think allocation is done via opengl
14:46Prf_Jakob: At least when talking to OpenXR clients
14:46emersion: or is it?
14:46pq: export from GL I've been told a very very bad idea
14:46Prf_Jakob: It's allocated on the OpenXR side of things and we use Vulkan there for allocation
14:46emersion: yeah, so it's imported in opengl
14:47emersion: not exported
14:47pq: oh, so it's *not* allocated with OpenGL
14:47emersion: in any case, no there is no shortcut here
14:47Prf_Jakob: I mean on some platforms it could be allocated in OpenGL, but from the client POW it's allocated by the OpenXR runtime magically and appears when it creates a XrSwapchain
14:47emersion: you need to use a platform, and no platform will just let you use "any gpu i don't care"
14:48pq: maybe OpenXR should become an EGL platform?
14:48Prf_Jakob: God no!
14:48Prf_Jakob: I mean it might help a bit
14:48Prf_Jakob: But would be a whole bunch of annoying code to write
14:48pq: you said you don't want apps need to use anything else, so I'm not sure how else it could work
14:49emersion: sometimes you have two GPUs, in which case you want egl to use the same gpu as vulkan
14:49Prf_Jakob: But you could have a env variable for that
14:49emersion: yeah it's not great
14:49emersion: it's a good workaround, nothing more
14:49Prf_Jakob: But right now I have a regression
14:49emersion: is the openxr app responsible for creating the egl display? i forget how it works
14:49Prf_Jakob: It used to work
14:50Prf_Jakob: I have shit to do
14:50Prf_Jakob: How can I fix this without having to result to wasting days
14:50emersion: i still don't understand what the issue is, tbh
14:50pq: Prf_Jakob, you keep saying it used to work. Did you bisect?
14:50emersion: apart from "it doesn't work"
14:50emersion: eglCreateDisplay(NULL) not working?
14:51Prf_Jakob: I call eglGetDisplay(null), I get a llvmpipe display, things explode when I try to create a XrSwapchain
14:51emersion: eglCreateDisplay(NULL) is pretty much the equivalent of "please make my app break someday"
14:52Prf_Jakob: I used to get accelerated OpenGL display
14:52Prf_Jakob: And since I only have one GPU it just worked
14:52ajax: sounds like you have a testcase you can feed to 'git bisect run', then?
14:53ajax: i mean. if it used to work, then it's mesa's fault it doesn't, so.
14:53Prf_Jakob: Sure, can git bisect apt packages?
14:53Prf_Jakob: I mean the first question was can I feed a fd into GBM in a easy way?
14:54Prf_Jakob: Or like poke the machinery underneath all this
14:54ajax: (sorry, i'm coming in late here)
14:54Prf_Jakob: Like fair enough: "No we don't have a env variable to do that" is a valid answer :p
14:55Prf_Jakob: But I'm suspecting that even if I use EGLDevice backend it will be broken because the error I posted above and MrCooper's answer sounds a lot like GBM got drunk along the way.
14:56MrCooper: doesn't the surfaceless platform just use "any gpu i don't care"?
14:56Prf_Jakob: That's right now fine with me because I only have one GPU.
14:56pq: Assuming just one GPU is a really bad experience (been there) when it's so easy to end up with integrated GPU + discrete GPU, even with both AMD.
14:56Prf_Jakob: Of course
14:57Prf_Jakob: But this is my little app that I'm using to develop for myself :p
14:57pq: Prf_Jakob, for surfaceless btw. I filed https://gitlab.freedesktop.org/mesa/mesa/-/issues/3987
14:57emersion: MrCooper: ah, yeah, i suppose i missed that one
14:59MrCooper: Prf_Jakob: GBM didn't get drunk, the application passed an unusable DRM file descriptor to gbm_create_device
14:59Prf_Jakob: MrCooper: No I didn't, some EGL code did.
14:59Prf_Jakob: I just called eglGetDisplay(null);
15:01MrCooper: I don't see any internal gbm_create_device calls in Mesa EGL code
15:01MrCooper: and the output in the issue looks like a GBM device is created first, then an EGL display
15:03Prf_Jakob: That's my code
15:03MrCooper: maybe you're hitting a different issue, possibly with similar symptoms
15:04Prf_Jakob: If no mesa EGL code is creating a GBM device, where is that error message coming from?
15:04MrCooper: git grep is your friend :)
15:08mareko: airlied: not yet
15:11pq: Does DRM_CAP_TIMESTAMP_MONOTONIC refer to CLOCK_MONOTONIC or CLOCK_MONOTONIC_RAW?
15:16pq: what defines that?
15:17vsyrjala: someone decided to use it?
15:17pq: I mean, in the kernel code
15:18pq: I saw some use of CLOCK_MONOTONIC, but not enough to feel like it would be any of those places. Just a few drivers but no core.
15:19vsyrjala: ktime_get() vs. ktime_get_raw() is maybe what you're asking? not sure
15:19pq: oh, yes, thanks
15:19emersion: plz send patch if docs aren't good
15:31pq: emersion, I didn't find anything to patch :-P
15:31emersion: for once :P
15:31pq: ...since there is nothing to patch
15:32pq: no cap docs at all, as I could find
15:32emersion: ehhh, wait
15:32emersion: pq: https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#userspace-api-structures
15:32emersion: not there = undocumented
15:33emersion: … yeah, the docs are still all over the place
15:33pq: those are client caps, what about kernel caps?
15:33emersion: not there = undocumented :S
15:34pq: I'll show myself out now ;-)
15:34Prf_Jakob: emersion: How can I select a surfaceless display?
15:34emersion: pq: https://cgit.freedesktop.org/drm-tip/tree/include/uapi/drm/drm.h#n628
15:34Prf_Jakob: For those following along: "EGL_PLATFORM=surfaceless ./my_prog" works
15:35emersion: see the client caps documented below, but… not the kernel caps
15:35emersion: Prf_Jakob: eglCreatePlatformDsiplayExt(PLATFORM, EGL_DEFAULT_DISPLAY)
15:35emersion: something among these lines
15:36emersion: bleh, let me give you the exact incantation
15:37Prf_Jakob: Thanks :)
15:37pq: Prf_Jakob, FWIW, Weston has all the code needed to properly detect and use SURFACELESS.
15:38emersion: eglGetPlatformDisplayEXT(EGL_PLATFORM_SURFACELESS_MESA, EGL_DEFAULT_DISPLAY, NULL)
15:38Prf_Jakob: emersion: Thanks
15:38pq: navigating all the needed EGL extensions is a bit of a chore
15:39emersion: the whole code should be similar to https://github.com/emersion/hello-wayland/blob/opengl/main.c#L125
15:40emersion: except replacing the eglGetPlatformDisplayEXT with what i gave you above
15:40emersion: oh, eh, surfaceless is KHR
15:41emersion: so yeah, you can use EGL_PLATFORM_SURFACELESS_KHR, and check for the EGL_KHR_surfaceless_context client extension
15:41emersion: ehhh, no, this is about surfaceless *contexts*
15:42ajax: which are also awesome, but different.
15:42Prf_Jakob: "EGL_PLATFORM=surfaceless ./my_prog"
15:42Prf_Jakob: Where as
15:42Prf_Jakob: "EGL_PLATFORM=drm ./my_prog"
15:42Prf_Jakob: does not returning the error above
15:43Prf_Jakob: But when I run surfaceless I do not get any configs back, which I used to, but that's fine I just needed to make my client handle that and Monado accept config == EGL_NO_CONFIG.
15:43Prf_Jakob: And then everything worked
15:45ajax: you don't get any configs back because the EGL spec has a missing stair
15:46ajax: and the default setting for EGL_SURFACE_TYPE (or whatever) is EGL_WINDOW_BIT
15:47ajax: which, since surfaceless does not have windows, zero configs will support. so you either have to explicitly set that to 0 instead, or make a configless context (which is way easier but not portable to imagination's egl iirc, if that's a thing you care about)
15:48Prf_Jakob: Sweeet! The 0 solved that
15:49ajax: i've been tempted to stick a few _eglDebug into eglChooseConfig for that kind of thing
15:49pq: configless context, surfaceless context, surfaceless platform with pbuffer surfaces, weston does it all if you care for examples (not very straightforward maybe)
15:49Prf_Jakob: Please do, ping me if you need it reviewed.
15:51Prf_Jakob: I really just need a accelerated OpenGL context
16:17zmike: mareko: so then is there any way to know at present if a surface will be created from a resource using a different format?
16:32zmike: this is regarding arb_texture_view...
16:39imirkin: zmike: you can create texture views of any glTexStorage-initiated texture
16:39imirkin: and such views may be used as fb attachments
16:39imirkin: one could distinguish between application susing glTexImage vs glTexStorage, but seems hardly worth it
16:40imirkin: also note that e.g. cube textures/arrays may be used interchangeably with 2d arrays (but thankfully not 3d textures)
16:40zmike: it would be worth it in my case so that I can cut down on codepaths that need to be compatible with multiple formats
16:41imirkin: ok. well i think all applications use tex storage nowadays :)
16:41imirkin: it's not like "only use texstorage if you want to make views"
16:41imirkin: it's "use texstorage if you want better perf since everything gets laid out at once"
16:42jekstrand: LOL "all" LOL These are GL apps, right? 😂🤣🙃
16:42imirkin: all the ones you care about perf on
16:42imirkin: i expect e.g. unity would do it for everything
16:42jekstrand: Oh, sure
16:43imirkin: and yeah, older ones won't. but for those, perf is probably less important
16:43imirkin: (relative to modern gpu perf)
16:44jekstrand: Sorry. You said "all [GL] applications use <insert modern thing here>" and I felt the need to comment. :-P
16:44imirkin: yeah, there's GL applications doing all sorts of stuff
16:45imirkin: zmike: also not exactly the same, but images can be cast to any format as well, and there are no restrictions there
16:45imirkin: (other than size compatibility, obv)
16:45zmike: yes, I've seen the chart
16:45zmike: an annoying problem to handle
16:46imirkin: what i mean is that you can use even glTexImage-created images for glBindImageTexture
16:46imirkin: not necessarily glTexStorage (unlike the input to glTextureView)
16:47imirkin: [although applications that are new enough to want images probably all use glTexStorage anyway]
16:47imirkin: [except the one that jekstrand wrote to spite me]
16:47zmike: yes, I suppose this is true
16:48zmike: jekstrand does have a lot of free time which is mostly used writing GL applications out of spite, as we all know
16:48imirkin: what's the problem with vk? you have to pre-declare the recasts ahead of time?
16:49zmike: the problem is that the list of compatible formats for a given image is not necessarily compatible to use with implicit modifiers
16:50zmike: so if I specify the formats then I get the expected functionality but I can't use modifiers
16:50imirkin: i suspect this doesn't happen in practice all too often...
16:50imirkin: maybe you can just copy the texture around when it happens
16:51zmike: it happens a lot
16:51imirkin: i just don't see RGBA32F textures getting recast as ASTC_5x5_SRGB too often
16:51imirkin: hm, ok =/
16:51zmike: I'm talking even minor ones like float to uint
16:51zmike: not even considering more complex cat's
16:51imirkin: right ... it could mean you have to "flush" the surface, etc
16:52zmike: well I'd have to choose between copying or losing modifiers
16:52zmike: not great
16:52imirkin: with hw drivers, they just figure out what they need to do given the current state of the surface
16:53imirkin: but with vk, you don't have such luxury i guess
16:53zmike: mostly I just pray that I don't get a hang
16:54imirkin: are you sure you're not working on nouveau?
16:55zmike: no, but I do get the most crashes on the nv vk driver
16:56imirkin: dunno what the current state of things is, but at least in the past, nv driver was pretty good at recovery
16:56zmike: their draw serialization is seriously busted
16:56zmike: yeah it's on par with Intel for sure
16:57zmike: Intel mostly just hangs if you promise to give it a ubo descriptor and then don't
16:58imirkin: but you promised!
16:59zmike: like losing my keys smh
17:56anholt: heads up: deqp-runner main branch now has some piglit support. some caveats listed in the README, but if you deal with flaky piglit tests or piglit's runner being slow or running you out of memory, then this may be helpful to you.
18:13mareko: zmike: there is no way
18:14zmike: mareko: okay, thanks 👍
18:15mareko: yeah, buffers and images can cast to anything. only samplers require immutability of the storage (meaning no reallocation for a GL texture ID)
18:16zmike: makes sense
18:16zmike: I'm still in pursuit of your perf and it turns out that modifiers are helpful 🤔
18:17mareko: you'll need the best DCC settings, otherwise it will be terrible
18:17zmike: yes, I'm just starting to try and work out how to achieve that
18:18zmike: furmark so far has the biggest gap I've seen where I'm only hitting 30% of radeonsi
18:19mareko: so there are more issues than the lack of DCC, because DCC alone can't cause that differene
18:19zmike: sure, that much is apparent to me haha
18:20zmike: but I have no ability to use any profiling tools atm since I don't have wsi/presentation handling, so it's a lot of speculation
18:20mareko: also radeonsi sucks at barriers and inserts more than are needed, so you can be faster before we fix that
18:21zmike: I've already gotten better flush bits than radeonsi on unigine heaven, but I'm still down a ways on perf there too
18:21zmike: I'll get there someday
18:22mareko: what better flush bits?
18:22zmike: I mean I've done the work to reduce barrier usage in that case
18:22mareko: I see
18:23mareko: radeonsi puts a barrier at every FB state change
18:23mareko: but in reality it sometimes doesn't have to
18:23zmike: I'm actually optimizing that exact case now
18:25zmike: I was reading through your vertex element handling for divisors this morning
18:25zmike: some neat stuff
18:26mareko: the main thing is that it doesn't recompile shaders for different divisors, and then there is the fast division
18:27zmike: I don't currently recompile for any vertex element changes, but I'
18:27zmike: m also just using vertex attrib api
18:27zmike: which, according to drawoverhead, is ultra ultra slow somehow
18:52jekstrand: cwabbott: So here's a thought about getting rid of nir_register....
18:53jekstrand: What if we added a nir_intrinsic_decl_register and treated that like a deref which nir_intrinsic_load/store_register[_indirect] would take.
18:54jekstrand: That would let us get rid of nir_register entirely without a new load/store_reg instruction type.
18:57alyssa: jekstrand: And then we can stop naming everything ssa_%u and just say $u :p
18:57jekstrand: alyssa: WFM
18:57alyssa: (We do that in the backend IR printer, it's easier on my stimulus-averse brain)
18:58imirkin: perhaps not much of a concern, but it'll make any program using registers for regular storage unreadable, no?
19:03alyssa: When there are 100x the SSA defs than register defs, it likely gets lost to noise?
19:03imirkin: yeah, i just mean pre-ssa, etc
19:04alyssa: do we use nir_register for anything other than out-of-ssa? nirr_variable yes, but _register?
19:04imirkin: oh, perhaps not. in that case it won't be an issue
19:05jekstrand: I've jotted down both ideas on #2058 so we don't forget them.
19:05anholt: vec4 backends use lots of registers (nir_to_tgsi for example)
19:05alyssa: So they do..
19:06jekstrand: We can special-case those intrinsics in nir_print if we want to make it prettier.
19:06anholt: yeah, that would probably be all I needed for sanity
19:06alyssa: ^ If we have special helpers for backends to ingest these intrinsics, nir_print can use them too
19:08jekstrand: Another advantage to the intrinsic mechanism is that we could do it piecemeal. Add the intrinsics and, support in regs_to_ssa, and a flag to from_ssa to generate them. Then move drivers over. Then delete nir_register and start doing the giant refactor of doom.
19:08jekstrand: I guess we can do load/store_reg_instr peacemeal too.
19:09jekstrand: So that doesn't matter so much.
19:15alyssa: jekstrand: I still don't quite get what nir_intrinsic_decl_register would provide that a constant value wouldn't
19:15alyssa: What's wrong with `intrinisc_store_reg ( indirect ssa_def, base const index, wrmask const idx )` interface?
19:15alyssa: [And backends that don't do indirects will get 0 for the indirect 100% of the time and can ignore it]
19:17jekstrand: alyssa: It provides a few things: 1. We can more easily vailidate that all uses have the right bit size. 2. back-ends have all the comps/bits information up-front(ish). 3. We still have use/def chains.
19:17jekstrand: I'm not sure how useful those three things are, though.
19:19anholt: jekstrand: do we get nice addressing math for register arrays? (freedreno uses them for temp arrays)
19:20jekstrand: anholt: Define "nice"
19:20anholt: no extraneous operations?
19:21anholt: (I don't really know what nir_lower_locals_to_regs() output would look like)
19:21jekstrand: I don't remember off-hand either.
19:22jekstrand: I think it assumes that all structs are split and then flattens arrays-of-arrays.
19:23jekstrand: And I think you get the array index not a byte offset
19:24anholt: yeah, I guess that pass would just make the new nir_register declaration and then use the same array indexing it's doing wright now?
19:24jekstrand: That's the idea, anyway.
19:24alyssa: jekstrand: Not sure either.. We throw away all that in our backends and just flatten to register->index, and don't seem to miss it all that much.
19:25jekstrand: We don't support indirects in the FS back-end.
19:25jekstrand: I guess we do in vec4
19:25alyssa: Validation can still be done in linear-time though it might take 2 passes.
19:26alyssa: comp/bits information is right there in the ssa_def if I'm not mistaken? twiddling with the intrinsic defs notwithstanding
19:26alyssa: and use/defs are mostly there for optimizations, and ideally these intrinsics only show up after the NIR is totally finalized (out_of_ssa is the last pass called)
19:27alyssa: (and I'm not sure how useful non-SSA use/def chains are to us anyway)
19:27jekstrand: We do use the use/def information in regs_to_ssa for whatever that's worth.
19:28jekstrand: I'm not sure it's necessary but we do use
19:30alyssa: that's a thing?
19:30jekstrand: We use it quite a bit for control-flow munging passes.
19:30alyssa: I see.
19:30jekstrand: switch to registers, re-arrange control-flow, switch back.
19:31jekstrand: Way easier than trying to patch up phis
19:31alyssa: That.. does change things a bit.
19:31jekstrand: We could do variables for that, in theory.
21:40Thaodan: Is there another way to read gpu temps on amdgpu then hwmon? radeon-profile reports a different max temp than reading hwmon via sysfs.
21:41airlied: danvet: just pushed drm-fixes to origin/master so we don't have the swapfile bug haning around in the tree
21:52danvet: airlied, +1
21:55imirkin: glad someone other than me uses swapfiles... that would not have been fun
21:56alyssa: I already lost all my data once this fortnight, dont need again
22:37LordKitsuna: Swap files? Zswap is the new hotness. Just compress your ram! Works great for memory leaks that happen to compress well :p
22:38LordKitsuna: Then fails when you have actual content overflow
22:40kisak: fwiw, I used to use zswap with several low memory systems and had to remove it because the just-before OOM memory compaction is beyond terrible. Single character refresh on an existing ssh connection every 10-20 minutes
22:42idr: Good grief... did 1996 call and try to sell us RAM Doubler?
22:43idr: Aw yeah!
22:44vsyrjala: argh. 5.12 cycle is a bit of a disaster it seems. iwlwifi just oopses, rtc-cmos WARNs, swapfile eats your disk
22:46bnieuwenhuizen: is there a way to disable the threaded gallium context in radeonsi?
22:46idr: bnieuwenhuizen: There's an environment variable... let me check.
22:47pepp: bnieuwenhuizen: GALLIUM_THREAD=0
23:45airlied: jekstrand: you are the oracle of vulkan versioning, got a minute to work through a messy question?
23:47airlied: if you have a vulkan instance version of 1.0 but a physical device version reporting 1.2 under that, can you use SPIR-V 1. with shader modules for that device?
23:47airlied: validation layers seem to say now, if you don't request an spi version > 1.0 when you care the instance