O Dynamic Triple Buffering para o GNOME está ainda em desenvolvimento para aumentar a GPU quando necessário

Confira !!



Proposto no início deste verão para o Mutter do GNOME foi a ideia de um buffer triplo da área de trabalho quando a GPU está atrasada , a fim de fazer com que essa carga extra aumente as frequências de clock da GPU para, por sua vez, voltar aos trilhos com renderização da área -Tempo. Uma terceira versão desse trabalho está se formando, embora seja tarde demais para ver com o lançamento iminente do GNOME 3.38.0.

Daniel van Vugt da Canonical tem trabalhado neste buffer triplo dinâmico para o compositor Mutter do GNOME devido à experiência lenta que ele às vezes vê com gráficos Intel em particular. Mudar do buffer duplo para o triplo leva a um trabalho suficiente que geralmente faz com que o estado de desempenho da GPU aumente.

Com esses patches em andamento, o buffer duplo seria preservado, exceto quando os tempos de apresentação fossem perdidos.

Seus patches "v3" para o Mutter que foram reunidos nos últimos dias podem ser encontrados por meio do triple-buffer-with-states-branch . Um dos patches continua explicando o trabalho que está sendo feito e o esforço para evitar o acréscimo de latência:
Enquanto o buffer duplo irá de IDLE para PRESENTING_MAX, o buffer triplo e superior encontrará o estado PRESENTING no meio.

No estado PRESENTING, um novo quadro pode ser agendado antes que o anterior conclua a apresentação. Mas neste estado não podemos usar `calcular_next_update_time_us` porque daria um` next_update_time_us` que é muito antigo (uma repetição), causando renderização prematura e alta latência. Em vez disso, calculamos o tempo da próxima atualização precisamente um intervalo de quadro após o último. Isso evita a criação de um aumento na latência que o buffer triplo cego ou superior faria, mas também permite um escalonamento implícito para o buffer triplo quando e se for necessário (o quadro anterior não é apresentado no tempo).

Desta forma, podemos atingir taxas de quadros mais altas de triple + buffering sem incorrer em latência mais alta (presumindo que o sistema pode acompanhar a renderização na taxa de atualização anunciada).

No final das contas, veremos como esse trabalho vai e se tudo vai bem poderia ser escolhido para o GNOME 3.40 na próxima primavera ou veremos se há garantia de retrocesso para um lançamento pontual do GNOME 3.38.x.


Fonte

Até a próxima !!