09:07 pq: emersion, what do you think, do you want to make a libdisplay-info release before mid-Jan?
09:54 wlb: wayland-protocols Merge request !103 closed (Draft: alternative present-timing protocol)
09:56 wlb: wayland-protocols Merge request !250 closed (build: move unstable protocols to staging)
12:17 wlb: weston Merge request !1421 opened by Pekka Paalanen (pq) libweston: drop weston_output_init() test workaround https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1421 [Core compositor]
12:23 Company: so, I've been thinking about this somewhat seriously after the recent dmabuf discussion in #dri-devel
12:23 Company: how much benefit do compositors get from apps using dmabufs vs shmem?
12:24 pq: depends on what kind of dmabuf and what kind of compositor (KMS, GPU or software compositing)
12:24 Company: because I don't see it as too hard to replace the GTK3 wl_shmem code with VkAllocateMemory() + wl_linux_dmabuf
12:25 emersion: please don't
12:25 emersion: rendering directly to a mmap'ed dmabuf will be super slow
12:26 pq: that depends on what kind of dmabuf
12:26 emersion: VkAllocateMemory() is like a dmabuf-dmabuf
12:26 soreau: if it ain't broke.. don't fix it :P
12:27 emersion: the composiutor is in a better place to figure out the best way to get the pixels on the GPU
12:27 emersion: and on which GPU
12:27 pq: FWIW, Weston does not support dmabuf with pixman-renderer, and never attempts to read dmabuf contents into CPU domain. So if it fails import to EGL, it's rejected.
12:27 soreau: Company: do you mean for a vulkan-only path? or something else..?
12:28 Company: I mean literally just as a replacement for the wl_shmem buffer
12:28 Company: that cairo draws to
12:28 Company: so that the compositor can aovid the glTexImage2D() calls
12:28 emersion:invokes MrCooper
12:29 soreau: Company: but wouldn't you have to upload the buffer to the gpu somehow anyway?
12:29 pq: Company, well, wl_shm buffers are explicitly optimal for CPU access. Dmabuf usually is not, so it's uncommon to attempt CPU access to dmabuf.
12:29 Company: but I have no idea if that's useful and what to care about when it is
12:30 Company: but it's not too hard code-wise, so if it's beneficial: why not
12:30 pq: Company, why do you think you can import such sw dmabuf into a hardware GPU EGL or VK context? I didn't think that worked in general.
12:30 emersion: pq, it is not a sw dmabuf
12:30 emersion: it is a GPU dmabuf mmapped for CPU rendering
12:30 pq: and if the dmabuf is importable to GPU hardware, then why would it be a good idea to render into it with CPU?
12:31 Company: it's not a good idea - it's just what GTK3 does
12:31 Company: all I want is to back the GTK3 buffer by memory that the GPU can use
12:32 emersion: if you do CPU rendering, just use wl_shm
12:32 Company: like, I'd imagine that on integrated GPUs, that shouldn't be too hard
12:32 pq: well, if you are only looking to move the glTexImage2D equivalent operation into client-side, that's fine. But then it's a copy, not drawing.
12:32 Company: I'm looking to avoid the glTexImage2D() call entirely
12:33 emersion: on integrated CPUs, the GPU memory is still special
12:33 emersion: integrated GPUs*
12:33 Company: but is it so special that it shouldn't be used as a cairo surface's buffer?
12:34 emersion: yes
12:34 Company: why is that?
12:34 pq: while integrated GPU memory is not behind a "slow" bus, it's still usually hostile towards CPU rendering I believe, at least due to the cache mode.
12:35 Company: I'd have thought that it's fine as long as it's HOST_CACHED
12:35 pq: like write-combining vs. writeback vs. uncached
12:36 soreau: Company: would this even work with !vulkan? or the plan would be to fall back in that case?
12:36 Company: soreau: the plan would be to fall back of course
12:36 Company: this would just be a fast path
12:36 soreau: hm
12:37 soreau: make sure to add an env var to force the fallback path :P
12:37 pq: if you pick a good caching mode for CPU rendering, does that not make GPU texturing from it more expensive?
12:37 Company: I'd have assumed something like DEVICE_LOCAL | HOST_CACHED would work
12:38 Company: my AMD doesn't have that, but Intel does
12:38 soreau: Company: but TBF, this sounds like a place for a gtk4 experiment, not gtk3 :P
12:39 Company: gtk4 doesn't render with Cairo
12:39 soreau: well, not always..?
12:39 Company: gtk4 renders with Cairo if eglInitialize() fails
12:40 Company: ie your GPU driver is broken
12:41 Company: Intel has 3 memory types on Vulkan: DEVICE_LOCAL, DEVICE_LOCAL | HOST_VISIBLE, and DEVICE_LOCAL | HOST_CACHED
12:42 soreau: well it wouldn't be too great if this idea caused some sort of bug, with performance or otherwise, that users have to hack around somehow
12:42 Company: and they all use the same 32GB heap, aka my RAM
12:42 Company: but I have no idea what that means
12:55 mango: Hi. I’m writing a simple Wayland background daemon just to kind of learn a bit about how writing Wayland clients work and all that. At the moment I’m making use of the viewport protocol to have the compositor scale my images for me and it’s working great, but I would also like fractional scaling. I’m trying to use the fractional scale protocol but I’m utter confused with how it works
12:56 mango: Specifically, the documentation says that if I have a surface of size 100x50, I should submit a buffer of size 150x75 (if scaling with 1.5)
12:56 mango: Does this mean that I need to manually scale the buffer up myself? Doesn’t that defeat the purpose of using viewport?
12:57 Company: you create a 150x75 buffer and set it via viewport to cover the 100x50 window
12:59 Company: but if you're using the viewport for your own scale anyway, then it doesn't matter to you if the output is fractionally scaled or not I guess?
12:59 zamundaaa[m]: mango: if you're having the compositor up- or downscale the image already, then fractional scaling is useless to you
13:00 mango: zamundaaa: At the moment the compositor does scaling for me, but only integer scaling to ceil(<my scale>)
13:00 zamundaaa[m]: mango: no, the compositor scales to the pixels on the screen
13:00 zamundaaa[m]: The logical size you tell it is just an intermediary coordinate space
13:03 wlb: weston Merge request !1422 opened by Pekka Paalanen (pq) Rename compositor/ to frontend/ https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1422 [Testing], [Weston frontend]
13:04 mango: zamundaaa: I see my issue, I’m not supposed to call set_buffer_scale anymore
13:04 mango: I missed that part of the docs
13:04 mango: All works fine now, cheers
13:05 pq: You can set_buffer_scale and make it work with wp_viewport, but it does make things more complicated for you and has no benefit.
13:23 pq: Actually, isn't it a compositor bug, if viewport destination size is set, and buffer scale affects the destination size? That's how I could understand what mango said.
13:30 emersion: lol re that MR: i was thinking about putting my protocol impls in frontend/
13:31 pq: user frontend vs. protocol frontend?
13:31 wlb: wayland Issue #428 opened by Gg wp (FrolovRuslan1) User help with XKB https://gitlab.freedesktop.org/wayland/wayland/-/issues/428
13:31 pq: or is it the backend that is user facing? hmm...
13:32 emersion: to me the compositor sts between the clients and KMS
13:32 emersion: that KMS-facing part is the backend, th client-facing part is frontend
13:33 emersion: but yeah, just my own view i suppose :P
13:33 pq: but it also includes UI aspects like configuration and CLI, right?
13:34 emersion: these are orthogonal to me
13:34 pq: side-end?
13:34 emersion: yeah :P
13:34 emersion: not sure if i could come up with a better name
13:35 emersion: (feel free to disregard my comments, this was more of a fun fact than anything else really)
13:35 pq: picking names is usually hard
13:36 emersion: just call it "other-end"
13:37 emersion: (j/k)
13:37 pq: "the thing that loads the compositor libs and configures the pieces into a working compositor"
13:38 pq: loader?
13:38 pq: maybe not
13:41 emersion: "core" doesn't sound right either
13:41 emersion: "main" is confusing
13:41 pq: yup, our core is in the compositor libs
13:42 emersion: ("main" to mean that it contains the main function but eh)
13:42 ManMower: scaffolding
13:42 pq: main.c is in there, but so is a lot more
13:43 emersion: "bin"?
13:44 pq: clients/ is separate, and it's full of bins
13:45 emersion: "weston" wouldn't be helpful
13:46 pq: There is already a Gitlab label "Weston frontend" for things in this dir.
14:13 wlb: weston Merge request !1423 opened by Pekka Paalanen (pq) backend-drm: store EDID data https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1423 [DRM/KMS backend]