-
Notifications
You must be signed in to change notification settings - Fork 343
backend/drm: move primary wlr_swapchain handling out of backend #2903
Conversation
0519f1a
to
1b0bf91
Compare
5e048fb
to
e3905e9
Compare
Seems like I'm hitting synchronization issues with this PR, on both AMD and Intel. The buffers seem to be scanned out by KMS before the draw is complete, or cleared before KMS is done with them. |
Fixed by #3027 |
efb4864
to
46f7a55
Compare
ace1aae
to
fc05b76
Compare
This is now ready to review. |
Overall LGTM, I don't think I understand fully everything but I got the gist of it. Do you want another reviewer on it? |
@kennylevinsen, if you had a bit of time to double-check this PR, that would be helpful! Let me know if you don't, no worries. :) @bl4ckb0ne, let me know if you have any specific questions about this PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Commit message nit: "we don't need a renderer not an allocator." - I suspect you meant "nor".
Have this been run on multi-GPU for testing? I only have boring single-GPU machines.
types/wlr_output.c
Outdated
@@ -706,6 +789,9 @@ static bool output_basic_test(struct wlr_output *output) { | |||
} | |||
|
|||
bool wlr_output_test(struct wlr_output *output) { | |||
if (!output_ensure_buffer(output)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want to attach buffers to the output before doing the basic output test? And do we even want wlr_output_test to attach buffers? Seems a bit intrusive.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good question. The reason a buffer is attached is that some backends might only be able to test a modeset if they have a buffer. This is the case of the DRM backend for instance, previously an empty black buffer was attached on modeset if none was provided by the compositor.
For the X11 and Wayland backends performing a modeset without a buffer doesn't really make sense either.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh yeah, it's also needed to test the modeset.
However, does it make sense to perform output_basic_test
before ensuring a buffer? This would let us bail out early from an obviously bad configuration without wasting time allocating and clearing buffers (possibly twice if we fall back to modifierless). I don't think output_basic_test
relies on the output from output_ensure_buffer
—the buffer tests have matching conditions in output_ensure_buffer
, and the direct scan-out resolution test shouldn't be relevant if we had to allocate the buffer.
It should also be noted that we now issue up to 3 tests towards the output impl from wlr_output_test
, as output_ensure_buffer
performs 1 or 2 tests of its own. This shouldn't be a problem if the test is sufficiently fast.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
However, does it make sense to perform output_basic_test before ensuring a buffer?
I've been wondering about this as well. Updated to allocate the buffer only if the basic test succeeds, we can always change this in the future if necessary.
Note, once the first test has allocated a swapchain+buffer, these are re-used in subsequent tests and commits, so the overhead shouldn't be too bad.
Fails in test:
|
3911291
to
6dd3b25
Compare
3edd5a1
to
b7ad57e
Compare
Fixed up multi-GPU issues: with |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. I'll take your word for multi-GPU being fixed. :)
This will be necessary for the primary buffer.
This allows the swapchain to be created with the correct resolution during a mode change.
Some backends need a buffer in order to be able to perform a modeset.
Sometimes we allocate a buffer with modifiers but then fail to perform a modeset with it. This can happen on Intel because of bandwidth limitations. To mitigate this issue, it's possible to re-allocate the buffer with modifiers. Add the logic to do so in wlr_output.
Historically we haven't allowed direct scan-out for legacy KMS, because legacy misses the functionality to make sure a buffer can be scanned out. However with renderer v6 the backend can't figure out anymore whether the buffer comes from its internal swap-chain, because the backend doesn't have an internal swap-chain. The legacy KMS API guarantees that the driver won't reject a buffer as long as it's been allocated with the same parameters as the previous one. Let's check this in legacy_crtc_test.
We can't nuke it completely, we still need it for multi-GPU.
We only accept SCANOUT, the buffer type should never be set to RENDER.
We can now just rely on the common code for this.
Unless we're dealing with a multi-GPU setup and the backend being initialized is secondary, we don't need a renderer nor an allocator. Stop initializing these.
b7ad57e
to
5b9a931
Compare
This is #2505 but with the DRM backend changes too. This essentially completes the plan laid out in #1352, while keeping the existing compositor-facing
wlr_output
API intact.get_primary_formats
Depends on: #2505Depends on: #2829Depends on: #3035