Use a stride that is a multiple of 256 #2182

mahkoh commented 2025年10月02日 16:23:11 +02:00

Describe your feature request

On integrated GPUs, the compositor might be able to import the buffer created by foot directly and display it without any additional copies compared to dmabuf.

However, AMD hardware requires images to have a stride that is a multiple of 256 which means that this zerocopy path fails for most window sizes because foot uses a tightly packed stride at the moment.

### Describe your feature request On integrated GPUs, the compositor might be able to import the buffer created by foot directly and display it without any additional copies compared to dmabuf. However, AMD hardware requires images to have a stride that is a multiple of 256 which means that this zerocopy path fails for most window sizes because foot uses a tightly packed stride at the moment.

dnkl commented 2025年10月03日 06:07:34 +02:00

I don't know how to verify we're hitting the zero-copy path, but for starters, I could write a patch that adds, say, tweak.stride-multiple for you to test?

If it works, we can keep it, with a default of 256.

I don't know how to verify we're hitting the zero-copy path, but for starters, I could write a patch that adds, say, `tweak.stride-multiple` for you to test? If it works, we can keep it, with a default of 256.

mahkoh commented 2025年10月03日 13:22:56 +02:00

I don't know how to verify we're hitting the zero-copy path

You can run the current master of https://github.com/mahkoh/jay. I'm not aware of any other compositor that tries to do this at the moment.

1. Enable debug logging: jay set-log-level debug
2. If you have multiple GPUs, ensure that your integrated GPU is used for rendering: jay randr card 0 primary, the number depends on which GPU is the iGPU
3. Look at the logs: jay log -f

>I don't know how to verify we're hitting the zero-copy path You can run the current master of https://github.com/mahkoh/jay. I'm not aware of any other compositor that tries to do this at the moment. 1. Enable debug logging: `jay set-log-level debug` 2. If you have multiple GPUs, ensure that your integrated GPU is used for rendering: `jay randr card 0 primary`, the number depends on which GPU is the iGPU 3. Look at the logs: `jay log -f`

dnkl commented 2025年10月04日 11:23:18 +02:00

Btw, I juse realized; importing one surface is faster if you direct-import it. The downside however is that you can't release the wayland buffer immediately, forcing foot to double-buffer instead. This is slow - in most cases slower than memcpy:ing the buffer. But exact numbers depend on what you're doing and how much changes there are between each frame.

This is obviously only an "issue" if you're releasing buffers immediately at all. If you don't (smithay doesn't - not sure what jay is based on?), then direct import is a win-win. If you do, then it's not an obvious win.

Btw, I juse realized; importing **one** surface is faster if you direct-import it. The downside however is that you can't release the wayland buffer immediately, forcing foot to double-buffer instead. This is slow - in most cases slower than memcpy:ing the buffer. But exact numbers depend on what you're doing and how much changes there are between each frame. This is obviously only an "issue" if you're releasing buffers immediately at all. If you don't (smithay doesn't - not sure what jay is based on?), then direct import is a win-win. If you do, then it's not an obvious win.

mahkoh commented 2025年10月04日 12:42:00 +02:00

This is slow - in most cases slower than memcpy:ing the buffer.

The compositor doesn't have access to a faster memcpy implementation than the client.

I've looked into this in the past but foot's requirements are not reasonable. Essentially, foot requires the compositor to perform the copy in the wl_surface.commit handler before processing or sending any other messages. This means that the copy has to be performed synchronously and cannot be offloaded to a helper thread or the GPU. Which means that if foot sends a large update, the entire desktop will lag because the compositor will miss the next vblank.

All shm uploads and downloads in Jay are asynchronously performed on helper threads, if a CPU copy is required; and in vulkan transfer or async compute queues if a GPU copy is required, so that progress on the vulkan graphics queue is not blocked by the up or download. This means that clients using wl_shm will never degrade the performance of the compositor (within reason) even at very large surface size.

There is also the issue that Jay allows the user to change the render API (opengl/vulkan) and the GPU used for rendering at runtime. Which means that I would have to not only perform a copy to GPU memory directly, I would additionally have to perform a copy to a CPU buffer so that I can re-upload the buffer when the GPU context changes.

>This is slow - in most cases slower than memcpy:ing the buffer. The compositor doesn't have access to a faster memcpy implementation than the client. I've looked into this in the past but foot's requirements are not reasonable. Essentially, foot requires the compositor to perform the copy in the wl_surface.commit handler before processing or sending any other messages. This means that the copy has to be performed synchronously and cannot be offloaded to a helper thread or the GPU. Which means that if foot sends a large update, the entire desktop will lag because the compositor will miss the next vblank. All shm uploads and downloads in Jay are asynchronously performed on helper threads, if a CPU copy is required; and in vulkan transfer or async compute queues if a GPU copy is required, so that progress on the vulkan graphics queue is not blocked by the up or download. This means that clients using wl_shm will never degrade the performance of the compositor (within reason) even at very large surface size. There is also the issue that Jay allows the user to change the render API (opengl/vulkan) and the GPU used for rendering at runtime. Which means that I would have to not *only* perform a copy to GPU memory directly, I would additionally have to perform a copy to a CPU buffer so that I can re-upload the buffer when the GPU context changes.

dnkl commented 2025年10月04日 15:25:33 +02:00

The compositor doesn't have access to a faster memcpy implementation than the client.

You're right. But my main point was simply to make sure you were aware that if jay was doing immediate releases, some of the wins on the compositor side would turn into an increased cost on the client side.

Without direct import, not doing immediate buffer release does mean a decrease in performance, system wide, since you now have to memcpy both in the client, and in the compositor. It's my understanding that this is the reason firefox (and foot) tend to perform badly under niri (something I've noticed myself, to the point where I can't use niri on my 4K monitor).

Essentially, foot requires the compositor to perform the copy in the wl_surface.commit handler before processing or sending any other messages.

You may very well be right - I don't know the details of your compositor. But really, the only requirement is that the buffer is returned to foot before the next frame callback (which is when foot will need a "new" buffer). But perhaps that translates to what you said.

But all of this is really irrelevant; I'm not trying to push anything on anyone, and foot handles buffers not being released immediate just fine. It even handles buffers not being released at all (but eating lots of RAM., obviously). Again, just making sure it's being understood that doing a direct import affects the ability to do immediate releases, and that that affects how the system as a whole performs. You seem to have a good understanding of all of this, so let's just drop this. If you happen to do any system-level benchmarks, either with immediate vs. non-immediate buffer releases, or GPU direct upload vs. copying, I'd be interested in the results.

> The compositor doesn't have access to a faster memcpy implementation than the client. You're right. But my main point was simply to make sure you were aware that **if** jay was doing immediate releases, some of the wins on the compositor side would turn into an increased cost on the client side. Without direct import, not doing immediate buffer release does mean a decrease in performance, system wide, since you now have to memcpy both in the client, and in the compositor. It's my understanding that this is the reason firefox (and foot) tend to perform badly under niri (something I've noticed myself, to the point where I can't use niri on my 4K monitor). > Essentially, foot requires the compositor to perform the copy in the wl_surface.commit handler before processing or sending any other messages. You may very well be right - I don't know the details of your compositor. But really, the only requirement is that the buffer is returned to foot before the next frame callback (which is when foot will need a "new" buffer). But perhaps that translates to what you said. But all of this is really irrelevant; I'm not trying to push anything on anyone, and foot handles buffers not being released immediate just fine. It even handles buffers not being released at all (but eating lots of RAM., obviously). Again, just making sure it's being understood that doing a direct import affects the ability to do immediate releases, and that that affects how the system as a whole performs. You seem to have a good understanding of all of this, so let's just drop this. If you happen to do any system-level benchmarks, either with immediate vs. non-immediate buffer releases, or GPU direct upload vs. copying, I'd be interested in the results.