05:28 Lynne: so radv flags shaderBufferFloat32AtomicAdd as supported, but not shaderImageFloat32AtomicAdd
05:29 Lynne: is there anything special about the way storage images are implemented in radv such that it cannot do atomic adds?
05:29 Lynne: (this is all navi3x only, ofc, I know navi2x and lower don't have atomic float ops)
05:30 HdkR: Yes :)
05:31 HdkR: Also note, the proprietary stack doesn't report shaderImageFloat32AtomicAdd either
05:34 Lynne: well, that was 6 wasted hours of refactoring
05:37 HdkR: Although it does have CAS, so theoretically could fudge it
05:38 Lynne: I think I'll just never use storage images for anything but final output now, not when strided bda is better
05:38 Lynne: are buffer atomics fudged too?
05:39 Lynne: or is the proprietary stack just lagging behind features no one but me wants to use?
05:41 HdkR: ISA document claims only min/max for f32 type. So it'll also likely translate to CAS
05:42 HdkR: Oh wait, misread
05:42 HdkR: It has proper atomic add f32
05:42 HdkR: on buffers*
05:43 HdkR: buffer_atomic_{cmpswap,min,max,add}_f32
05:44 Lynne: fun fact, nvidia's had this for many generations now
05:44 Lynne: no idea why amd implemented it, but I'm glad they did
05:50 kode54: guess I should have gotten an RDNA3 card
10:14 MrCooper: benjaminl: no need to do anything, the pipeline will run automatically for Marge Bot
15:57 karolherbst: mareko: fyi, I've bisected a CL regression regarding 1Darray clears to https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25221/diffs?commit_id=3f44a8321f38890fefc1c553ad80810b61611e18
15:58 karolherbst: not quite sure what the problem is yet
16:03 karolherbst: but it looks like the image gets only partly filled
16:34 karolherbst: mhhh
16:35 karolherbst: filling an entire 1Darray image seems to work perfectly
16:35 karolherbst: but if it's just done partially it doesn't write values where they are expected
16:44 karolherbst: I think I see it...
16:48 karolherbst: yep...
16:49 karolherbst: mareko: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25221#note_2117775
17:37 Pegasusae`-: I​R​C.​​​​‌‍UNR​EALIRCD.ORG #UNREAL​​​​‌‬​-S​UPPOR⁠T
17:37 Pegasusae`-: PEGASUS WE​LCOMES​ YOU
17:37 Pegasusae`-: T⁠HE ON​LY IRCD​​​​​‬​​ THAT ​​​​‬​‬B​A⁠N​S NIGGERS BY DEFAULT​​​​‬​​
17:37 Pegasusae`-: Pegasusae`- heat_ cyrinux junaid TMM JohnnyonFlame DodoGTA MrCooper glennk kzd ungeskriptet Lyude Company fab kts Danct12 acidburn_ mvchtz pinchartl Haaninjo camus pcercuei sima lemonzest Duke`` crabbedhaloablut vyivel Leopold_ alanc co1umbarius shoragan shashanks_ Surkow|laptop ayaka swiftgeek OftenTimeConsuming i-garrison neniagh rz hikiko yang3 rsalvaterra pochu darkglow kxkamil3 dtmrzgl1
17:37 Pegasusae`-: enunes lcn soreau xzhan34 flto phire ascent12_ Emantor DragoonAethis oneforall2 unerlige lucenera Ryback_ pzanoni lstrano shankaru rsripada fdu dolphin aswar002 tristianc6704 Amber_Harmonia pixelcluster ced117 agd5f dliviu lileo pjakobsson g0b fkassabri[m] pushqrdx[m] Kayden orowith2os[m] moben[m] kunal_10185[m] bylaws gdevi sigmoidfunc[m] cwfitzgerald[m] jtatz[m] YHNdnzj[moz] enick_991
17:37 Pegasusae`-: AlexisHernndezGuzmn[m] sergi1 Vin[m] bubblethink[m] naheemsays[m] ella-0[m] T_UNIX pankart[m] vdavid003[m] MayeulC pp123[m] undvasistas[m] daniliberman[m] ids1024[m] yshui` Targetball[m] BilalElmoussaoui[m] EricCurtin[m] tomeu talcohen[m] minecrell nicofee[m] benjaminl gnustomp[m] samueldr ofirbitt[m] dantob Tooniis[m] MotiH[m] kallisti5[m] sravn gildekel sarnex aradhya7[m] dhirschfeld2[m] Omax
17:37 Pegasusae`-: knr tak2hu[m] digetx KunalAgarwal[m][m] i509vcb zamundaaa[m] kusma exp80[m] znullptr[m] Quinten[m] ram15[m] Peuc x512[m] DPA2 aura[m] Vanfanel cmeissl[m] Ella[m] nekit[m] Thymo egalli JosExpsito[m] ohadsharabi[m] gallo[m] tintou Wallbraker Armote[m] enick_185 Mershl[m] treeq[m] hch12907 sghuge Frogging101 cyrozap zzxyb[m] Sumera[m] dos1 doras heftig ttayar[m] vidal72[m] tomba masush5[m] jasuarez
17:37 Pegasusae`-: AlaaEmad[m] Newbyte Eighth_Doctor jenatali Guest2233 Sofi[m] kode54 nick1343[m] kos_tom zzoon_OOO_till_03_Oct[m] rppt emersion bl4ckb0ne Nefsen402 halfline[m] kelbaz[m] dcbaker Hazematman K0bin[m] siddh reactormonk[m] tleydxdy nielsdg doraskayo q4a msizanoen[m] dabrain34[m]1 YaLTeR[m] shoffmeister[m] FloGrauper[m] viciouss[m] jernej robertmader[m] isinyaaa[m] Anson[m] nyorain[m] koike xerpi[m]
17:37 Pegasusae`-: kunal10710[m] DemiMarie ajhalaney[m] devarsht[m] onox[m] swick[m] CME leo60228 mmind00 gio krumelmonster jeeeun841351 dschuermann rcn-ee___ ccaione aradhya7 praneeth_ macromorgan_ pq RSpliet zf xroumegue greaser|q Kwiboo a-865 glehmann Venemo DavidHeidelberg cns CATS karolherbst anarsoul imre psykose zehortigoza neggles orbea paulk anujp jmondi robmur01 sauce yrlf konstantin kurufu egbert
17:37 Pegasusae`-: alarumbe illwieckz bbrezillon tango_ moxie danylo rcf clamps vaxry nchery opotin65 Plagman qyliss Adrinael Net147 gfxstrand Mangix jhli CosmicPenguin steve--w mal cef mauld kem anholt noord yogesh_m1 sumoon kchibisov ella-0 rosefromthedead rpigott kennylevinsen ifreund bnieuwenhuizen sre ndufresne nuclearcat2 akselmo Ristovski dv_ italove8 the_sea_peoples mwk_ tarceri libv xxmitsu KitsuWhooa
17:37 ungeskriptet: stop
17:37 Pegasusae`-: exit70 dwlsalmeida jkhsjdhjs RAOF mattst88 Namarrgon phryk xypron melonai arnd robher kerneltoast jimjams eric_engestrom dianders zx2c4 zmike rodrigovivi rib daniels steev austriancoder zzag markco mdnavare hfink hashar rg3igalia olv linusw q66 linkmauve immibis azerov Stary invertedoftc09691 xantoz kugel mareko dri-logger glisse vup sknebel krh ogabbay vignesh benettig ernstp tfiga
17:37 Pegasusae`-: SanchayanMaity vgpu-arthur pundir norris NishanthMenon linyaa kathleen_ tchar ddavenport_ jhugo appusony____ naseer__ angular_mike______ _alice lvrp16 jluthra haasn pendingchaos seanpaul hwentlan_ cheako sskras jstultz cwabbott TimurTabi vaishali ezequielg khilman urja vjaquez ishitatsuyuki tlwoerner MoeIcenowy _whitelogger UndeadLeech _isinyaaa bcheng airlied jolan KungFuJesus wens Shibe rossy
17:37 Pegasusae`-: graphitemaster narmstrong rcombs kisak SolarAquarion gabertron Lightsword clever jrayhawk schaeffer thaytan smaeul JPEW bwidawsk robclark nirmoy nicolejadeyee jbarnes caseif_ _lemes codingkoopa32 robink sh-zam Simonx22 radii_ siqueira MTCoster demarchi andrey-konovalov kallisti5 sumits melissawen cmarcelo ManMower abhinav__ lumag quantum5 jessica_24 jljusten ZeZu hays JTL swivel lumidify Scorpi
17:37 Pegasusae`-: romangg V vsyrjala pa- leandrohrb5 tanty jani samuelig rellla ickle kj marcan jcristau shadeslayer zamundaaa mupuf HdkR tagr jkqxz_ javierm eloy_ uajain gpiccoli pH5 ivyl derRichard JoshuaAshton pepp puck_ CounterPillow Arsen any1 gruetzkopf hakzsam lucaceresoli LaserEyess kgz klounge Mary sebastiencs aleasto BobBeck9 haagch rawoul wv a1batross sven Koniiiik dj-death llyyr mlankhorst iokill ds`
17:38 emersion: maybe we ought to restore mute-unauth-users for a while
17:38 siddh: Cmon, I am tired of this spam every alternate day across IRC and matrix rooms
17:40 emersion: sad but oh well
17:41 i509vcb: I never understood people deopping themselves after doing something? Is it a case of not accidentally running a command or because bots will spam dm ops?
17:41 HdkR: oh naur
17:42 kchibisov: emersion: is there a +s thing like on libera? They don't spam secret channels iirc.
17:43 emersion: yes, there is +s
17:49 phryk: beep boop, can you read this?
17:49 i509vcb: yes
17:50 macromorgan: It is, on occasion, nice when you don't have to make guesses about a person's intellect; such as the Pega-whatever person above.
17:52 phryk: \o/
17:53 Nefsen402: queue the meme of the futuristic world with the dog walker if oftc finally stops randomly unauthenticating you
17:54 karolherbst: I'm sure it's probably fine to require authentication generally...
17:55 karolherbst: just wished that IRC networks would provide easier ways to authenticate
17:55 psykose: sasl is easy, but oftc, well...
17:55 emersion: most do, except OFTC
17:55 phryk: anybody up for some mentoring? i'm looking to do write my own ui toolkit in D, but libdrm header macros are too weird for it to be directly usable with ease so now I want to write a small C library that abstracts libdrm + opengl/vk for buffer creation – but I'm a bit confused. :P
17:56 emersion: what macro exactly?
17:56 emersion: and why is libdrm needed for a ui toolkit?
17:57 phryk: at least all of the macros that are parameterized. didn't even know that was a thing before i stumbled over this with libdrm.
17:57 emersion: i haven't seen a lot of macros in libdrm
17:58 phryk: emersion: oh, i might've said that wrong. i want to write at least one wayland compositor (maybe two, one to replace the tty) *and* a ui toolkit – i'm just not sure yet how/where to split the two so i currently just see it as one project.^^
18:02 Nefsen402: phryk: Writing a wayland compositor with graphics complex enough to warrant a toolkit means you're doing it wrong. You should instead ofload that kind of stuff to a wayland client to work in conjunction with the compositor
18:02 phryk: Nefsen402: you mean the compositor should not contain any ui at all? o_O
18:04 Nefsen402: ideally
18:04 phryk: quite honestly, even for the tty replacement one, i'd want re-usable graphical components…
18:05 Nefsen402: the tty replacement one can be built with off the shelf components:
18:05 Nefsen402: A kiosk type wayland compositor and any old terminal emulator
18:05 phryk: yeah, and then it'll do exactly what current ttys do and not be any sort of improvement :F
18:06 Nefsen402: What improvements could be made?
18:07 phryk: extra spaces for system stats, logtails, human-readable notifications – honestly I'd want to make that thing modular because i'm sure there's a lot of useful stuff that i won't think of.
18:08 phryk: also, i want fucking electropaint on my tty and i can't die before i get that done :D
18:08 Nefsen402: All of that can be done with a specialized client implementing it all, or better yet using more off the shelf components like mako, foot, a layer shell status bar and a compositor putting that together
18:09 emersion: phryk: what Nefsen is trying to say that you can have UI even if the compositor doesn't draw it. wayland clients can be in charge of drawing your compositor's UI, for instance
18:10 phryk: emersion: so, equating this with x11, the compositor would have more or less the role of the x server (mainly modesetting + ipc for clients in my understanding) and then it'd run a client that more or less equates to an x11 window manager?
18:12 emersion: no
18:12 Nefsen402: Trying to fit a wayland system into boxes that x11 has will set you up for pain. The compositor will still be responsible for positioning your clients
18:12 phryk: then please explain what the compositor and client in your concept actually do.
18:12 emersion: a client can be in charge of drawing the top bar, or notifications, without being responsible for managing other windows
18:13 emersion: you can look at existing compositors (except GNOME), they do exactly this
18:15 phryk: mhh. okay. the compositor would still handle setting modes, creating buffers and rendering clients to them, correct?
18:16 Nefsen402: the client will still render to buffers and pass them back to you but it's the compositor's responsibility to render those buffers to the output swapchain
18:17 phryk: swapchain? is that a fancy word for the buffers in double buffering?
18:18 Nefsen402: kms/drm can lock more than one buffer at a time. You'll want at least 3 buffers in rotation
18:19 phryk: why 3? back in the day i last dabbled with graphics programming (mid-00s) double buffering was the norm and the man pages for drm seem to imply that's still the case, if i'm not mistaken.
18:20 Nefsen402: 1 currently displayed on the screen, 1 queued for display next flip and 1 you're currently rendering to
18:21 phryk: i fail to see what the practical difference to double buffering is – would you elaborate a bit? ^^;
18:22 phryk: does this improve vsync or framepacing or somesuch thing?
18:23 Nefsen402: you risk missing a page flip deadline if you only use two buffers
18:24 Nefsen402: (well, you always risk it if rendering takes longer than your refresh period but you'll get substantially more room with 3 buffers)
18:25 phryk: i have never heard that term before. if a frame takes too long to render, you'd get tearing if you don't have vsync active, in which case the frame would be delayed until the next flip.
18:25 phryk: at least that's how i remember things from Back Then™
18:25 Nefsen402: atomic kms doesn't support tearing
18:26 Nefsen402: You'll get EBUSY if you try to hand over a new buffer before vblank
18:26 Nefsen402: (patches are in the works to "fix" that though)
18:27 phryk: so… what's the bad thing that happens when i miss a pageflip deadline?
18:27 Nefsen402: you increase latency
18:28 phryk: ah, so it is purely a frame pacing thing?
18:28 phryk: alright, sounds easy enough and i guess buffers are cheap enough that triple buffering by default doesn't lock anyone with cheap gpus out. :)
18:29 Nefsen402: Note that not all hw supports tearing
18:29 Nefsen402: or asynchonous page flips aka
18:30 phryk: i'm confused by that wording. iirc tearing is the artifact you get from running a single-buffered application where frame rendering time doesn't align with the display refresh rate.
18:31 phryk: i.e. you get a "cut" on the display above which the new frame is shown and below which the old one is still visible.
18:31 phryk: or the other way around, don't shoot me :P
18:31 Nefsen402: you get tearing when you page flip outside of vblank
18:32 Nefsen402: it has nothing to do with "single-buffered" rendering
18:32 Nefsen402: it's just really easy to get with front buffer rendering
18:32 phryk: alright, makes sense.
18:32 JohnnyonFlame: I've had tearing on triple-buffered setups due to broken vsync on some amlogic boards fwiw
18:34 phryk: if it's not opening too big a can of worms: how does variable sync a la freesync/gsync figure into this?
18:34 Nefsen402: nothing. All it does it extend the so-called "front porch" before the actual pixel signal is sent
18:35 Nefsen402: it basically gives you some leaway if you miss vblank by a bit
18:35 Nefsen402: imagine it as not being variable refresh rate but as variable vblank time
18:36 phryk: ah, makes sense. sounds like it should be possible to add support for it later without havint to re-engineer everything. :)
18:37 phryk: okay, taking it back to where i'm curently at: libdrm + buffers. i already got a little code working to query connectors and supported modes. if i'm not mistaken buffer creation would be the next thing i need on my road to get to rendering on the displays – is that right?
18:38 Nefsen402: you can allocate buffers with gbm
18:38 Nefsen402: then you can get the fd of those dmabufs you recieve to hand over to drm when you're ready
18:38 phryk: hearing of that for the first time. not having a man page for that – is there documentation somewhere?
18:39 Nefsen402: "gbm buffer allocator" on google shows results
18:39 phryk: because previously, my impression was that i either create a libdrm "dumb buffer" for software rendering or an opengl/vulkan one using that library and then somehow hook up the resulting buffer with the display.
18:40 emersion: i would recommend using an existing compositor, instead of trying to build a new one
18:40 phryk: no matter if i end up using it, i think writing one is kind of critical for me to actually learn the lay of the land.
18:41 Nefsen402: I think vulkan can be used to allocate drmbufs that you can use with kms but I'm not sure.
18:41 emersion: no, it can't
18:41 emersion: unless you're fine with crossing fingers very hard
18:41 Nefsen402: what's the vulkan allocator in wlroots for then?
18:41 emersion: it's not merged, and can be used with non-KMS backends
18:42 Nefsen402: ah
18:44 phryk: so if i want to render with opengl, i'll create a buffer with gbm and hook that up with opengl *and* libdrm?
18:44 Nefsen402: yes
18:44 Nefsen402: it's not that different with vulkan
18:45 Nefsen402: you just need to import the buffers into whatever rendering api you want to use
18:46 phryk: so it also works for software rendering when hardware acceleration isn't available?
18:47 Nefsen402: yes, those dmabufs will just live on main memory and still be managed by the kernel as usual
18:48 Nefsen402: although, it's hard to find a device these days with a display port connector and direct from system memory scanout
18:48 phryk: main memory = "normal" ram? can gbm buffers be vram-only?
18:48 Nefsen402: >main memory = "normal" ram yes
18:48 Nefsen402: gbm buffers can live wherever the kernel wants them to live
18:49 Nefsen402: they can live on multiple devices as well
18:49 Nefsen402: you don't really have control
18:49 phryk: so, when reading the drm man pages, i stumbled over dumb, gem and ttm buffers – gbm seems like the unified buffer interface i was missing in there, does that sound about right?
18:50 Nefsen402: that's outside of my domain of knowledge
18:51 phryk: fair enough. i'll just accept that gbm is a viable way to get buffers to hook up with drm as well as gl/vk for now. :)
18:52 phryk: i think i have a fair enough grasp on connectors and modes, but i'm struggling to grok crtcs and encoders – any words of wisdom you could share on those?^^
18:52 Nefsen402: robust crtc allocation is a bastard. I'll leave you as that.
18:54 phryk: is there a high-level overview of the relation between them somewhere? i'm not sure on what they even do – or rather why they are two different things, if they have some fixed connections in hardware, etc.
18:55 JohnnyonFlame: I'd highly recommend reading throuhg https://www.kernel.org/doc/html/v4.18/gpu/drm-kms.html
18:55 i509vcb: Nefsen402: Last I recall there was some experiments we did in smithay where nvidia was a little more happy importing amdgpu buffers allocated by vulkan where was gbm crashes
18:55 i509vcb: although it's very fragile still from what I recall as well
18:55 phryk: JohnnyonFlame: thanks. :)
18:56 Nefsen402: i509vcb: The union of modifier support by nvidia and amdgpu is basically nothing. If linear was being used, I would be worried about other things
18:56 i509vcb: I think it was linear
18:57 Nefsen402: nvidia can't render to linear so the setup wouldn't work the other way round
18:57 i509vcb: multigpu stuff in the compositor can be a real pain
18:57 Nefsen402: yeah, at that point you need to copy through the CPU
18:57 zamundaaa[m]: Yes, with OpenGL that's your only choice. With Vulkan you can make it work though
18:58 phryk: when i got my gbm buffer hooked up to gl/vulkan, in order to hook it up to the display, i have to pass it into drmModeGetFB[2] to create a framebuffer and that one i can actually hook up to the display, right?
18:59 zamundaaa[m]: phryk: yes
18:59 phryk: do i need planes for double/triple buffering or can i just ignore planes for now?
19:00 i509vcb: zamundaaa[m]: I don't think nvidia advertises COLOR_ATTACHMENT on any linear tilings in vulkan. Sampling appears to be supported sometimes but that's more for import
19:00 Nefsen402: You can't ignore planes because you'll always have to render to one: the primary
19:01 phryk: oh, so are planes how i hook up framebuffers to a display?
19:01 Nefsen402: basically, yes
19:02 phryk: great. i think i got enough info to get started, thanks for all the patient help. :)
19:04 zamundaaa[m]: i509vcb: yes, but you should be able to render to a tiled texture and afterwards copy to a linear one
19:04 zamundaaa[m]: With OpenGL you don't even get that
19:05 i509vcb: okay yeah that makes sense
19:23 phryk: mhh, do i have to call anything except open() on the device file before gbm_create_device? getting "amdgpu_device_initialize: amdgpu_query_info(ACCEL_WORKING) failed (-13)"…
19:25 phryk: my user definitely has the right permissions to access the graphics card and drmModeGetResources for example works fine with an fd that's constructed in the same way as what i pass into gbm_create_device.
19:27 Nefsen402: in the past, doing precisely that worked for me.. huh
19:27 phryk: i'd rtfm but "No manual entry for gbm_create_device" :P
19:28 phryk: Nefsen402: it can't be because i already have x running on both displays, right? if i understand correctly "normal" applications using accelerated rendering would also use gbm to set up their rendering?
19:29 Nefsen402: normall applications would typically just use whatever buffers opengl/vulkan gives them combined with wsi
19:30 phryk: wsi is… wayland server implementation?
19:31 Nefsen402: But I have been able to simply open(/dev/dri/card0) and pass the fd to gbm_allocator_create for a stupid simple compositor benchmark
19:31 zamundaaa[m]: phryk Wsi means window system integration
19:31 Nefsen402: gbm_create_device* rather
19:32 phryk: Nefsen402: https://paste.xinu.at/4pYPAo/ this is my code, maybe i just suck too much at C? ^^
19:32 phryk: __builtin_dump_struct is llvm/clang specific in case you're wondering.
19:32 zamundaaa[m]: To use the card nodes you need to be drm master
19:33 zamundaaa[m]: For tests like that you'll want to use /dev/dri/render128
19:34 phryk: card nodes? drm master?^^
19:34 phryk: the latter one i can at least fathom what it means. i assume X is currently drm master on my system?
19:41 zamundaaa[m]: Yes
19:41 phryk: and by card nodes you just mean /dev/dri/card*?
19:43 phryk: i can at the very least still query drm resources when X is running, hence my confusion.
19:49 zamundaaa[m]: <phryk> "and by card nodes you just mean..." <- Yes
19:51 zamundaaa[m]: <phryk> "i can at the very least still..." <- Not every action requires privilidges. Querying the resources and properties doesn't for example, but changing them or reading from the fb does
19:52 phryk: alright. gonna drop out of X for a bit and see if it works when run from the tty without X already hogging the device.
19:55 phryk: it does. or at least i don't get the error message anymore, but the struct seems to have no members – is that normal?
20:09 phryk: same goes for gbm_bo_create, but hey at least on the surface it seems like buffer creation already works. :)
20:37 immibis: client-side Wayland decorations are an abomination, a crime against humanity. The compositor - or something related to the compositor - should be in charge of drawing the compositor's decorations.
20:37 immibis: there is absolutely no excuse for demanding all apps to draw their own title bars and borders. That's braindead design.
20:38 immibis: of course it's fine to give apps the option to do that in case they want nonstandard ones
20:43 emersion: please tone down your tone
20:43 phryk: immibis: is this in reply to anything?
20:43 emersion: and this is off-topic
20:43 immibis: yes, some people talking about window decorations in Wayland and how they should be handled by clients...
20:44 psykose: wouldn't be a year without at least 782315 ssd/csd heated debates
20:45 phryk: immibis: i think one of us might have misunderstood things. you are replying to people telling me the compositor shouldn't render ui, right?
20:46 immibis: yes and specifically window decorations
20:47 immibis: Wayland is a mess with respect to window decorations overall. You can use the braindead GNOME design or the less braindead KDE design, but there's no right answer or good answer - which is part of the reason Wayland hasn't taken over the desktop
20:47 phryk: if decorations where specifically talked about i missed that. but i'd definitely say that applications shouldn't have to draw their own decorations. i was under the impression that you can have one central client to handle all the windowing, essentially.
20:47 phryk: because if not, i'll *definitely* need a ui toolkit in my compositor.^^
20:48 immibis: X11 has pretty clear roles for what the different parts do, but it seems like Wayland doesn't - sure there's a spec, and there are big gaps in the spec where the correct behavior is "whatever everyone else is doing"
20:48 phryk: honestly, i'd even go so far that applications *shouldn't* draw their own decorations. that always seemed like a ux nightmare to me…
20:49 immibis: GNOME thinks apps should have to draw their own decorations and they are extremely stubborn on this and will actually ban you if you say they shouldn't. KDE takes the practical approach where the compositor draws the decorations.
20:49 phryk: wait, so any application that doesn't render its own decorations just becomes unclosable on gnome? o_O
20:49 immibis: so, like, you'd better test things on both because they are functionally different protocols
20:49 immibis: Yes.
20:50 immibis: Lots of people think GNOME 3 jumped the shark and you're experiencing that now
20:50 phryk: well, that's <expletive> <expletive>. the most obvious failure mode you can think of and they don't even handle that?
20:50 immibis: they would probably tell you you're in the wrong for using Wayland directly instead of using GTK, which renders the decorations
20:50 immibis: actually, a lot of applications have quit options in their menus, which will work
20:51 phryk: right. still pretty horrible ux-wise…
20:51 immibis: it's the same attitude that brought us systemd and dbus. Both of which were heavily pushed by GNOME, IIRC
20:52 phryk: no idea how one would get to consistent window decorations for the entire desktop being a bad thing @_@
20:52 immibis: GNOME is basically designed to be its own operating system - you're not a Linux app, you're a GNOME app and you better fit into the GNOME system or else. Whereas KDE is taking what exists and making it work for the user.
20:52 immibis: well you get consistent decorations because every app uses GTK, of course :)
20:53 phryk: right, lol.
20:53 phryk: i definitely have gtk and qt stuff on my system. and running neither gnome nor kde…
20:54 phryk: not a fan of gtk tho because the only tool to set basic shit like the theme is… gnome. :F
20:54 immibis: in the GNOME view Wayland is basically an internal IPC interface for GTK to communicate with whatever compositor GNOME uses. Like the CSRSS protocol in windows. You don't speak to CSRSS in windows, you call the functions in user32.dll
20:54 immibis: and you don't speak to the compositor in GNOME, you call GTK functions
20:57 phryk: immibis: this kinda stuff is a big part of why i want to write my own small ui toolkit… i want something that is *by design* independent from the compositor/wm/de.
20:58 immibis: there's no complete independence but I expect both the gnome and kde toolkits and every other one are like that. As you say, GTK apps work without gnome
21:01 ndufresne: Yes, make your own toolkit, it will be much better then anything anyone ever made before (maybe ... in phew years)
21:02 DavidHeidelberg: immibis: please move the discussion to the appropriate channels. Most appreciated :)
21:02 immibis: is it blocking a discussion you are trying to have?
21:03 immibis: or do you get pinged by every message in this channel?
21:03 psykose: no but it generates unread markers of weird diatribe nobody wants to read
21:03 DavidHeidelberg: this is logged channel, people except to find relevant information here time to time
21:03 DavidHeidelberg: *expect
21:13 DavidHeidelberg: zmike: anholt MR which fixes reference image upload: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25606
21:13 zmike: \o/
21:41 kurufu: Is it possible to disable vulkan extensions like with MESA_EXTENSION_OVERRIDE ?
21:57 airlied: maybe in the loader
21:58 airlied: oh I think it only does some hacky stuff for instance exts
22:15 kurufu: Yea i saw the instance exts stuff, but i wanted to disable multidraw and dynamic state3 since renderdoc doesnt support those yet.
22:16 kurufu: building the driver without them advertised seemed to work but would be annoying if i didnt have mesa laying around
23:50 Company: doesn't renderdoc have its own loader that disables unsupported extensions?
23:51 Company: lst time I tried it, it failed properly for me because my code tried to enable descriptor indexing