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.
<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
<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