Skip to content

Conversation

cmeissl
Copy link
Contributor

@cmeissl cmeissl commented Apr 20, 2025

At this point just a poc, which obviously needs a major cleanup, showcasing and tracking Smithay/smithay#1720

// Expose syncobj protocol if supported by primary GPU
if supports_syncobj_eventfd(&device_fd) {
let syncobj_state = DrmSyncobjState::new::<State>(&niri.display_handle, device_fd);
assert!(self.syncobj_state.replace(syncobj_state).is_none());
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Guess this should be removed once the primary node is removed?

let mut min_next_schedule: Option<Duration> = None;

for (output, target_presentation_time, refresh_interval) in queued_outputs {
let next_deadline = self.signal_commit_timing(&output, target_presentation_time);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this happen at the start of refresh() together with the call to notify_blocker_cleared()? As I understand, this signalling clears blockers for the surfaces that now became ready, which means it should happen earlier, so that the commits are considered by layout.refresh().

let output = output.clone();
self.redraw(backend, &output);
}
pub fn queued_outputs(&self) -> Vec<(Output, Duration, Option<Duration>)> {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess this is not exactly queued_outputs() since it doesn't check if the output is queued for redraw?

if self.niri.is_queued(&output) {
self.niri
.redraw(&mut self.backend, &output, target_presentation_time);
self.signal_fifo(&output);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I entirely understand how fifo is supposed/intended to work. In the protocol:

This means that when the content update containing "set_barrier" was made active at a latching deadline, it will be active for at least one refresh cycle.

What happens if we redraw and signal fifo here, but the redraw doesn't actually submit a buffer (e.g. the damage was outside the output rect), then something else commits right away and we redraw and signal again, before one refresh cycle had passed? Doesn't this go against this line in the protocol?

if self.niri.is_queued(&output) {
self.niri
.redraw(&mut self.backend, &output, target_presentation_time);
self.signal_fifo(&output);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same question here about clearing commit blockers at the end here, after layout.refresh(). Though this one is trickier because I understand it has to happen after a redraw which itself has to happen at the end.

@helixoid
Copy link

When is it going to be implemented.
Only major blocker for nvidia users like me.
Also will there be support for wp-color-mangement-v1 (HDR) in future?

@YaLTeR
Copy link
Owner

YaLTeR commented Jul 24, 2025

How exactly is this a blocker? Many people use niri on NVIDIA just fine.

@helixoid
Copy link

It just flickers, or so I've heard. NVIDIA doesn’t support implicit sync.

@YaLTeR
Copy link
Owner

YaLTeR commented Jul 25, 2025

You've heard wrong. The screencast flickers are unrelated to this PR. Nvidia has a workaround for lack of explicit sync since long ago and it works fine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants