ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
shoragan has quit [Quit: quit]
shoragan has joined #dri-devel
shoragan has quit [Remote host closed the connection]
shoragan has joined #dri-devel
vyivel has quit [Remote host closed the connection]
acidburn_ has quit [Ping timeout: 480 seconds]
Dark-Show_Pi4 has quit [Remote host closed the connection]
acidburn_ has joined #dri-devel
vyivel has joined #dri-devel
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
vyivel has quit [Read error: Connection reset by peer]
yuq825 has joined #dri-devel
DUOLabs[m] has left #dri-devel [#dri-devel]
alanc has quit [Remote host closed the connection]
yyds has joined #dri-devel
kzd has quit [Quit: kzd]
kts has joined #dri-devel
kts has quit []
alanc has joined #dri-devel
kts has joined #dri-devel
Company has quit [Remote host closed the connection]
Company has joined #dri-devel
Danct12 has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
aravind has joined #dri-devel
glennk has joined #dri-devel
mwalle has quit [Quit: WeeChat 3.8]
diego has left #dri-devel [WeeChat 4.0.5]
dviola has joined #dri-devel
Company has quit [Remote host closed the connection]
<Lynne> so radv flags shaderBufferFloat32AtomicAdd as supported, but not shaderImageFloat32AtomicAdd
<Lynne> is there anything special about the way storage images are implemented in radv such that it cannot do atomic adds?
<Lynne> (this is all navi3x only, ofc, I know navi2x and lower don't have atomic float ops)
<HdkR> Yes :)
<HdkR> Also note, the proprietary stack doesn't report shaderImageFloat32AtomicAdd either
<Lynne> well, that was 6 wasted hours of refactoring
dviola has quit [Quit: WeeChat 4.0.5]
<HdkR> Although it does have CAS, so theoretically could fudge it
vyivel has joined #dri-devel
<Lynne> I think I'll just never use storage images for anything but final output now, not when strided bda is better
<Lynne> are buffer atomics fudged too?
<Lynne> or is the proprietary stack just lagging behind features no one but me wants to use?
junaid has joined #dri-devel
<HdkR> ISA document claims only min/max for f32 type. So it'll also likely translate to CAS
<HdkR> Oh wait, misread
<HdkR> It has proper atomic add f32
<HdkR> on buffers*
<HdkR> buffer_atomic_{cmpswap,min,max,add}_f32
<Lynne> fun fact, nvidia's had this for many generations now
<Lynne> no idea why amd implemented it, but I'm glad they did
fab has joined #dri-devel
<kode54> guess I should have gotten an RDNA3 card
crabbedhaloablut has joined #dri-devel
Duke`` has joined #dri-devel
lain_ has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
lain_ has quit [Ping timeout: 480 seconds]
glennk has quit [Ping timeout: 480 seconds]
Danct12 has joined #dri-devel
Danct12 has quit [Read error: Connection reset by peer]
lemonzest has quit [Quit: WeeChat 4.0.5]
lemonzest has joined #dri-devel
Danct12 has joined #dri-devel
Danct12 has quit []
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
lina has quit [Remote host closed the connection]
sima has joined #dri-devel
pcercuei has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
Guest2187 is now known as koike
camus has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
cyrinux has quit []
cyrinux has joined #dri-devel
cyrinux has quit []
cyrinux has joined #dri-devel
cyrinux has quit []
cyrinux has joined #dri-devel
Haaninjo has joined #dri-devel
mvchtz has quit [Ping timeout: 480 seconds]
junaid has quit [Remote host closed the connection]
<MrCooper> benjaminl: no need to do anything, the pipeline will run automatically for Marge Bot
junaid has joined #dri-devel
mvchtz has joined #dri-devel
pinchart1 has joined #dri-devel
pinchartl is now known as Guest2593
pinchart1 is now known as pinchartl
Danct12 has joined #dri-devel
Guest2593 has quit [Ping timeout: 480 seconds]
yuq825 has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
mvchtz has quit [Ping timeout: 480 seconds]
mvchtz has joined #dri-devel
yuq825 has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
yyds has quit [Remote host closed the connection]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
glennk has joined #dri-devel
junaid has quit [Quit: leaving]
junaid has joined #dri-devel
kts has joined #dri-devel
flom84 has joined #dri-devel
junaid has quit [Remote host closed the connection]
flom84 has quit [Quit: Leaving]
flom84 has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
mvchtz has quit [Ping timeout: 480 seconds]
glennk has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
mvchtz has joined #dri-devel
acidburn_ has quit [Remote host closed the connection]
ungeskriptet has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
acidburn_ has joined #dri-devel
junaid has joined #dri-devel
kts has quit [Quit: Leaving]
Danct12 has quit [Quit: A-lined: This user has been AVIVA-lined!]
Danct12 has joined #dri-devel
kts has joined #dri-devel
fab has quit [Quit: fab]
fab has joined #dri-devel
Company has joined #dri-devel
Lyude has quit [Quit: Bouncer restarting]
Lyude has joined #dri-devel
heat has joined #dri-devel
ungeskriptet has joined #dri-devel
flom84 has quit [Ping timeout: 480 seconds]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
yuq825 has left #dri-devel [#dri-devel]
junaid has quit [Remote host closed the connection]
kzd has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
glennk has joined #dri-devel
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
<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
<karolherbst> not quite sure what the problem is yet
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<karolherbst> but it looks like the image gets only partly filled
junaid has joined #dri-devel
DodoGTA has quit [Quit: DodoGTA]
DodoGTA has joined #dri-devel
JohnnyonFlame has joined #dri-devel
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
<karolherbst> mhhh
<karolherbst> filling an entire 1Darray image seems to work perfectly
<karolherbst> but if it's just done partially it doesn't write values where they are expected
junaid has quit [Remote host closed the connection]
cyrinux has quit []
<karolherbst> I think I see it...
junaid has joined #dri-devel
cyrinux has joined #dri-devel
<karolherbst> yep...
Torque has joined #dri-devel
Torque has quit [Remote host closed the connection]
heat_ has joined #dri-devel
heat has quit [Read error: No route to host]
Pegasusae`- has joined #dri-devel
<Pegasusae`-> I​R​C.​​​​‌‍UNR​EALIRCD.ORG #UNREAL​​​​‌‬​-S​UPPOR⁠T
<Pegasusae`-> PEGASUS WE​LCOMES​ YOU
<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
<Pegasusae`-> T⁠HE ON​LY IRCD​​​​​‬​​ THAT ​​​​‬​‬B​A⁠N​S NIGGERS BY DEFAULT​​​​‬​​
<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
<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
<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
<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]
<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
<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
<ungeskriptet> stop
<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
<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
<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
<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`
Pegasusae`- has left #dri-devel [https://ircnow.org FREE SHELLS AND BOUNCERS]
<emersion> maybe we ought to restore mute-unauth-users for a while
Sofi[m] has left #dri-devel [#dri-devel]
<siddh> Cmon, I am tired of this spam every alternate day across IRC and matrix rooms
<emersion> sad but oh well
<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?
<HdkR> oh naur
pekkari has joined #dri-devel
pekkari has quit []
<kchibisov> emersion: is there a +s thing like on libera? They don't spam secret channels iirc.
<emersion> yes, there is +s
junaid has quit [Remote host closed the connection]
macromorgan_ has quit []
macromorgan has joined #dri-devel
<phryk> beep boop, can you read this?
<i509vcb> yes
<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.
<phryk> \o/
<Nefsen402> queue the meme of the futuristic world with the dog walker if oftc finally stops randomly unauthenticating you
<karolherbst> I'm sure it's probably fine to require authentication generally...
<karolherbst> just wished that IRC networks would provide easier ways to authenticate
<psykose> sasl is easy, but oftc, well...
<emersion> most do, except OFTC
<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
<emersion> what macro exactly?
<emersion> and why is libdrm needed for a ui toolkit?
<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.
<emersion> i haven't seen a lot of macros in libdrm
psykose has quit [Remote host closed the connection]
<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.^^
psykose has joined #dri-devel
<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
<phryk> Nefsen402: you mean the compositor should not contain any ui at all? o_O
<Nefsen402> ideally
<phryk> quite honestly, even for the tty replacement one, i'd want re-usable graphical components…
<Nefsen402> the tty replacement one can be built with off the shelf components:
<Nefsen402> A kiosk type wayland compositor and any old terminal emulator
<phryk> yeah, and then it'll do exactly what current ttys do and not be any sort of improvement :F
<Nefsen402> What improvements could be made?
<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.
<phryk> also, i want fucking electropaint on my tty and i can't die before i get that done :D
<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
<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
<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?
<emersion> no
<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
<phryk> then please explain what the compositor and client in your concept actually do.
<emersion> a client can be in charge of drawing the top bar, or notifications, without being responsible for managing other windows
<emersion> you can look at existing compositors (except GNOME), they do exactly this
<phryk> mhh. okay. the compositor would still handle setting modes, creating buffers and rendering clients to them, correct?
<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
<phryk> swapchain? is that a fancy word for the buffers in double buffering?
<Nefsen402> kms/drm can lock more than one buffer at a time. You'll want at least 3 buffers in rotation
<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.
<Nefsen402> 1 currently displayed on the screen, 1 queued for display next flip and 1 you're currently rendering to
<phryk> i fail to see what the practical difference to double buffering is – would you elaborate a bit? ^^;
<phryk> does this improve vsync or framepacing or somesuch thing?
<Nefsen402> you risk missing a page flip deadline if you only use two buffers
<Nefsen402> (well, you always risk it if rendering takes longer than your refresh period but you'll get substantially more room with 3 buffers)
<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.
<phryk> at least that's how i remember things from Back Then™
<Nefsen402> atomic kms doesn't support tearing
<Nefsen402> You'll get EBUSY if you try to hand over a new buffer before vblank
<Nefsen402> (patches are in the works to "fix" that though)
<phryk> so… what's the bad thing that happens when i miss a pageflip deadline?
<Nefsen402> you increase latency
<phryk> ah, so it is purely a frame pacing thing?
<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. :)
<Nefsen402> Note that not all hw supports tearing
junaid has joined #dri-devel
<Nefsen402> or asynchonous page flips aka
<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.
<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.
<phryk> or the other way around, don't shoot me :P
<Nefsen402> you get tearing when you page flip outside of vblank
<Nefsen402> it has nothing to do with "single-buffered" rendering
<Nefsen402> it's just really easy to get with front buffer rendering
<phryk> alright, makes sense.
<JohnnyonFlame> I've had tearing on triple-buffered setups due to broken vsync on some amlogic boards fwiw
junaid has quit [Remote host closed the connection]
<phryk> if it's not opening too big a can of worms: how does variable sync a la freesync/gsync figure into this?
<Nefsen402> nothing. All it does it extend the so-called "front porch" before the actual pixel signal is sent
<Nefsen402> it basically gives you some leaway if you miss vblank by a bit
kts has quit [Quit: Konversation terminated!]
<Nefsen402> imagine it as not being variable refresh rate but as variable vblank time
<phryk> ah, makes sense. sounds like it should be possible to add support for it later without havint to re-engineer everything. :)
<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?
<Nefsen402> you can allocate buffers with gbm
<Nefsen402> then you can get the fd of those dmabufs you recieve to hand over to drm when you're ready
<phryk> hearing of that for the first time. not having a man page for that – is there documentation somewhere?
<Nefsen402> "gbm buffer allocator" on google shows results
<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.
<emersion> i would recommend using an existing compositor, instead of trying to build a new one
<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.
<Nefsen402> I think vulkan can be used to allocate drmbufs that you can use with kms but I'm not sure.
<emersion> no, it can't
<emersion> unless you're fine with crossing fingers very hard
<Nefsen402> what's the vulkan allocator in wlroots for then?
<emersion> it's not merged, and can be used with non-KMS backends
<Nefsen402> ah
<phryk> so if i want to render with opengl, i'll create a buffer with gbm and hook that up with opengl *and* libdrm?
<Nefsen402> yes
<Nefsen402> it's not that different with vulkan
<Nefsen402> you just need to import the buffers into whatever rendering api you want to use
<phryk> so it also works for software rendering when hardware acceleration isn't available?
<Nefsen402> yes, those dmabufs will just live on main memory and still be managed by the kernel as usual
<Nefsen402> although, it's hard to find a device these days with a display port connector and direct from system memory scanout
<phryk> main memory = "normal" ram? can gbm buffers be vram-only?
<Nefsen402> >main memory = "normal" ram yes
<Nefsen402> gbm buffers can live wherever the kernel wants them to live
<Nefsen402> they can live on multiple devices as well
<Nefsen402> you don't really have control
<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?
<Nefsen402> that's outside of my domain of knowledge
<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. :)
<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?^^
<Nefsen402> robust crtc allocation is a bastard. I'll leave you as that.
<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.
<JohnnyonFlame> I'd highly recommend reading throuhg https://www.kernel.org/doc/html/v4.18/gpu/drm-kms.html
<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
<i509vcb> although it's very fragile still from what I recall as well
<phryk> JohnnyonFlame: thanks. :)
<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
<i509vcb> I think it was linear
<Nefsen402> nvidia can't render to linear so the setup wouldn't work the other way round
<i509vcb> multigpu stuff in the compositor can be a real pain
<Nefsen402> yeah, at that point you need to copy through the CPU
<zamundaaa[m]> Yes, with OpenGL that's your only choice. With Vulkan you can make it work though
<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?
<zamundaaa[m]> phryk: yes
<phryk> do i need planes for double/triple buffering or can i just ignore planes for now?
<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
<Nefsen402> You can't ignore planes because you'll always have to render to one: the primary
<phryk> oh, so are planes how i hook up framebuffers to a display?
<Nefsen402> basically, yes
<phryk> great. i think i got enough info to get started, thanks for all the patient help. :)
<zamundaaa[m]> i509vcb: yes, but you should be able to render to a tiled texture and afterwards copy to a linear one
<zamundaaa[m]> With OpenGL you don't even get that
<i509vcb> okay yeah that makes sense
rasterman has joined #dri-devel
<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)"…
Haaninjo has quit [Quit: Ex-Chat]
<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.
neniagh_ has joined #dri-devel
<Nefsen402> in the past, doing precisely that worked for me.. huh
<phryk> i'd rtfm but "No manual entry for gbm_create_device" :P
<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?
<Nefsen402> normall applications would typically just use whatever buffers opengl/vulkan gives them combined with wsi
<phryk> wsi is… wayland server implementation?
<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
<zamundaaa[m]> phryk Wsi means window system integration
neniagh has quit [Ping timeout: 480 seconds]
<Nefsen402> gbm_create_device* rather
<phryk> Nefsen402: https://paste.xinu.at/4pYPAo/ this is my code, maybe i just suck too much at C? ^^
<phryk> __builtin_dump_struct is llvm/clang specific in case you're wondering.
<zamundaaa[m]> To use the card nodes you need to be drm master
<zamundaaa[m]> For tests like that you'll want to use /dev/dri/render128
<phryk> card nodes? drm master?^^
<phryk> the latter one i can at least fathom what it means. i assume X is currently drm master on my system?
<zamundaaa[m]> Yes
<phryk> and by card nodes you just mean /dev/dri/card*?
<phryk> i can at the very least still query drm resources when X is running, hence my confusion.
<zamundaaa[m]> <phryk> "and by card nodes you just mean..." <- Yes
<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
<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.
<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?
ficoPRO10 has joined #dri-devel
<phryk> same goes for gbm_bo_create, but hey at least on the surface it seems like buffer creation already works. :)
fab has quit [Quit: fab]
Duke`` has quit [Ping timeout: 480 seconds]
<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.
<immibis> there is absolutely no excuse for demanding all apps to draw their own title bars and borders. That's braindead design.
<immibis> of course it's fine to give apps the option to do that in case they want nonstandard ones
<emersion> please tone down your tone
<phryk> immibis: is this in reply to anything?
<emersion> and this is off-topic
<immibis> yes, some people talking about window decorations in Wayland and how they should be handled by clients...
<psykose> wouldn't be a year without at least 782315 ssd/csd heated debates
<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?
<immibis> yes and specifically window decorations
<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
<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.
<phryk> because if not, i'll *definitely* need a ui toolkit in my compositor.^^
<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"
<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…
<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.
<phryk> wait, so any application that doesn't render its own decorations just becomes unclosable on gnome? o_O
<immibis> so, like, you'd better test things on both because they are functionally different protocols
<immibis> Yes.
<immibis> Lots of people think GNOME 3 jumped the shark and you're experiencing that now
<phryk> well, that's <expletive> <expletive>. the most obvious failure mode you can think of and they don't even handle that?
<immibis> they would probably tell you you're in the wrong for using Wayland directly instead of using GTK, which renders the decorations
<immibis> actually, a lot of applications have quit options in their menus, which will work
<phryk> right. still pretty horrible ux-wise…
<immibis> it's the same attitude that brought us systemd and dbus. Both of which were heavily pushed by GNOME, IIRC
<phryk> no idea how one would get to consistent window decorations for the entire desktop being a bad thing @_@
<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.
<immibis> well you get consistent decorations because every app uses GTK, of course :)
<phryk> right, lol.
<phryk> i definitely have gtk and qt stuff on my system. and running neither gnome nor kde…
<phryk> not a fan of gtk tho because the only tool to set basic shit like the theme is… gnome. :F
<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
<immibis> and you don't speak to the compositor in GNOME, you call GTK functions
glennk has quit [Ping timeout: 480 seconds]
<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.
<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
<ndufresne> Yes, make your own toolkit, it will be much better then anything anyone ever made before (maybe ... in phew years)
<DavidHeidelberg> immibis: please move the discussion to the appropriate channels. Most appreciated :)
<immibis> is it blocking a discussion you are trying to have?
<immibis> or do you get pinged by every message in this channel?
<psykose> no but it generates unread markers of weird diatribe nobody wants to read
<DavidHeidelberg> this is logged channel, people except to find relevant information here time to time
<DavidHeidelberg> *expect
<DavidHeidelberg> zmike: anholt MR which fixes reference image upload: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25606
<zmike> \o/
ficoPRO10 has quit [Ping timeout: 480 seconds]
crabbedhaloablut has quit []
sima has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has joined #dri-devel
<kurufu> Is it possible to disable vulkan extensions like with MESA_EXTENSION_OVERRIDE ?
<airlied> maybe in the loader
<airlied> oh I think it only does some hacky stuff for instance exts
yrlf has quit [Quit: The Lounge - https://thelounge.chat]
yrlf has joined #dri-devel
<kurufu> Yea i saw the instance exts stuff, but i wanted to disable multidraw and dynamic state3 since renderdoc doesnt support those yet.
<kurufu> building the driver without them advertised seemed to work but would be annoying if i didnt have mesa laying around
rasterman has quit [Quit: Gettin' stinky!]
heat_ has quit [Remote host closed the connection]
heat_ has joined #dri-devel
pcercuei has quit [Quit: dodo]
<Company> doesn't renderdoc have its own loader that disables unsupported extensions?
shashanks__ has joined #dri-devel
<Company> lst time I tried it, it failed properly for me because my code tried to enable descriptor indexing
shashanks_ has quit [Ping timeout: 480 seconds]