ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
floof58 has quit [Ping timeout: 480 seconds]
Brainium has quit [Remote host closed the connection]
<Company>
so, I've been thinking about this somewhat seriously after the recent dmabuf discussion in #dri-devel
<Company>
how much benefit do compositors get from apps using dmabufs vs shmem?
<pq>
depends on what kind of dmabuf and what kind of compositor (KMS, GPU or software compositing)
<Company>
because I don't see it as too hard to replace the GTK3 wl_shmem code with VkAllocateMemory() + wl_linux_dmabuf
<emersion>
please don't
<emersion>
rendering directly to a mmap'ed dmabuf will be super slow
<pq>
that depends on what kind of dmabuf
<emersion>
VkAllocateMemory() is like a dmabuf-dmabuf
<soreau>
if it ain't broke.. don't fix it :P
<emersion>
the composiutor is in a better place to figure out the best way to get the pixels on the GPU
<emersion>
and on which GPU
<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.
<soreau>
Company: do you mean for a vulkan-only path? or something else..?
<Company>
I mean literally just as a replacement for the wl_shmem buffer
<Company>
that cairo draws to
<Company>
so that the compositor can aovid the glTexImage2D() calls
* emersion
invokes MrCooper
<soreau>
Company: but wouldn't you have to upload the buffer to the gpu somehow anyway?
<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.
<Company>
but I have no idea if that's useful and what to care about when it is
<Company>
but it's not too hard code-wise, so if it's beneficial: why not
<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.
<emersion>
pq, it is not a sw dmabuf
<emersion>
it is a GPU dmabuf mmapped for CPU rendering
<pq>
and if the dmabuf is importable to GPU hardware, then why would it be a good idea to render into it with CPU?
<Company>
it's not a good idea - it's just what GTK3 does
<Company>
all I want is to back the GTK3 buffer by memory that the GPU can use
<emersion>
if you do CPU rendering, just use wl_shm
<Company>
like, I'd imagine that on integrated GPUs, that shouldn't be too hard
<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.
<Company>
I'm looking to avoid the glTexImage2D() call entirely
<emersion>
on integrated CPUs, the GPU memory is still special
<emersion>
integrated GPUs*
<Company>
but is it so special that it shouldn't be used as a cairo surface's buffer?
<emersion>
yes
<Company>
why is that?
<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.
<Company>
I'd have thought that it's fine as long as it's HOST_CACHED
<pq>
like write-combining vs. writeback vs. uncached
<soreau>
Company: would this even work with !vulkan? or the plan would be to fall back in that case?
<Company>
soreau: the plan would be to fall back of course
<Company>
this would just be a fast path
<soreau>
hm
<soreau>
make sure to add an env var to force the fallback path :P
<pq>
if you pick a good caching mode for CPU rendering, does that not make GPU texturing from it more expensive?
<Company>
I'd have assumed something like DEVICE_LOCAL | HOST_CACHED would work
<Company>
my AMD doesn't have that, but Intel does
<soreau>
Company: but TBF, this sounds like a place for a gtk4 experiment, not gtk3 :P
<Company>
gtk4 doesn't render with Cairo
<soreau>
well, not always..?
<Company>
gtk4 renders with Cairo if eglInitialize() fails
<Company>
ie your GPU driver is broken
<Company>
Intel has 3 memory types on Vulkan: DEVICE_LOCAL, DEVICE_LOCAL | HOST_VISIBLE, and DEVICE_LOCAL | HOST_CACHED
<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
<Company>
and they all use the same 32GB heap, aka my RAM
<Company>
but I have no idea what that means
kts has joined #wayland
mango has joined #wayland
<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
<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)
<mango>
Does this mean that I need to manually scale the buffer up myself? Doesn’t that defeat the purpose of using viewport?
<Company>
you create a 150x75 buffer and set it via viewport to cover the 100x50 window
<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?
<zamundaaa[m]>
mango: if you're having the compositor up- or downscale the image already, then fractional scaling is useless to you
<mango>
zamundaaa: At the moment the compositor does scaling for me, but only integer scaling to ceil(<my scale>)
<zamundaaa[m]>
mango: no, the compositor scales to the pixels on the screen
<zamundaaa[m]>
The logical size you tell it is just an intermediary coordinate space
<mango>
zamundaaa: I see my issue, I’m not supposed to call set_buffer_scale anymore
<mango>
I missed that part of the docs
<mango>
All works fine now, cheers
<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.
mango has quit [Quit: leaving]
garnacho has quit [Quit: garnacho]
kts has quit [Quit: Leaving]
<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.
garnacho has joined #wayland
Moprius has joined #wayland
<emersion>
lol re that MR: i was thinking about putting my protocol impls in frontend/