Motor nasıl çalışır

OLED Guard Pro bir ekran koruyucu değildir. Bilgisayarını kullanırken her frame'i, bağlı her ekranda işleyen, GPU üzerinde çalışan gerçek zamanlı bir video boru hattıdır. Bu sayfa teknik turdur.

Dört aşamalı boru hattı

   ┌──────────┐     ┌──────────┐     ┌──────────┐     ┌──────────┐
   │ CAPTURE  │ ──▶ │  MODEL   │ ──▶ │  POLICY  │ ──▶ │COMPOSITE │
   │  DXGI    │     │ exposure │     │ Auto/man │     │   DWM    │
   └──────────┘     └──────────┘     └──────────┘     └──────────┘

1. Yakalama: DXGI Desktop Duplication

Windows, Desktop Duplication adında bir API sunar; bu API, DWM'in belirli bir ekran için oluşturduğu görüntü her değiştiğinde sana bir GPU doku tutamacı verir. Bunu kullanmamızın nedenleri:

  • GPU üzerinde çalışır. Frame buffer asla video belleğinden ayrılmaz.
  • Kenarlıksız tam ekran oyunların içinde (çoğu oyuncunun gerçekte oynadığı mod) çalışan tek genel Windows API'sidir. BitBlt veya PrintWindow gibi eski yaklaşımlar çalışmaz.
  • HDR, çoklu monitör ve yüksek yenileme hızlı ekranları, bizim özel bir şey yapmamıza gerek kalmadan destekler.

2. Model: piksel başına maruziyet shader'ı

Bir piksel shader'ı, yakalanan her frame'i yerel çözünürlükte işler. Her piksel için şunu hesaplar:

luminance     = dot(pixelRGB, vec3(0.2126, 0.7152, 0.0722));
delta         = luminance * frameTime;
exposure[p]   = exposure[p] + delta;

İki paralel geçiş de çalışır:

  • Hareket zarfı. Ucuz bir zamansal yüksek geçiş: bu piksel son N frame'de ne kadar değişti? Hareketi yüksek olan piksellerin maruziyeti daha hızlı azalır, çünkü hareketli içerik yaşlanmayı tek bir noktada yoğunlaştırmaz.
  • Kararlılık dedektörü. Hareket zarfı üzerinde bir alçak geçiş: değeri birçok frame boyunca kararlı kalan piksellerin “statik” olduğu işaretlenir ve bunlar koruma için aday olur.

Maruziyet histogramı GPU belleğinde çift tamponlanır. Sıcak yolda CPU'ya geri okuma yoktur.

3. Policy: bu konuda ne yapılacağı

Policy aşaması, piksel başına, her frame'de üç şeye karar verir:

  • Ne kadar koruma uygulanacağı.
  • Ne tür bir katman işleneceği: gürültü (varsayılan), statik karartma, pixel shift veya dithering, isteğe bağlı olarak üstüne vinyet tarzı bir kenar ağırlıklandırması eklenerek.
  • Nerede alanın şekillendirileceği: tek tip, kenarlara doğru vinyet ağırlıklı veya app-profile geometrisi tarafından yönlendirilmiş.

Manuel modda bu değerler Katman sayfasındaki sürgülerden gelir. Otomatik Mod'da controller, canlı sinyal sınıflandırmasına (iş, oyun, video, boşta), piksel başına hareket zarfına ve dinamizm izine bakar ve modelin, bir algılanabilirlik bütçesine bağlı kalarak riski en aza indirdiğini söylediği bir yapılandırma seçer. Bunun gerçekleştiğini Advanced > Live Classifier göstergesinde izleyebilirsin.

4. Composite: DWM ön çarpımlı alfa

İkinci bir shader, seçilen katmanı şeffaf ve her zaman en üstte duran bir pencereye işler. Desktop Window Manager o pencereyi masaüstüne ön çarpımlı alfa kullanarak birleştirir: Windows'un kendi animasyonları için kullandığı yolun aynısı. Katmanın şu durumlarda doğru çalışmasının nedeni budur:

  • SDR ve HDR modlarında,
  • kenarlıksız tam ekran oyunlarda,
  • değişken yenileme hızlı ekranlarda (G-Sync / FreeSync),
  • çoklu monitör kurulumlarında,
  • karışık DPI yapılandırmalarında.

Asıl harmanlamayı DWM yapar. Biz sadece bir frame sağlıyoruz.

Ekran başına, paralel olarak

Bağlı her ekran, boru hattının kendi kopyasını çalıştırır. Durum paylaşmazlar. Bir monitör değişikliği, bir hot-plug, bir çözünürlük değişikliği: motor bunu fark eder, etkilenen boru hattını bırakır ve diğerlerini rahatsız etmeden yeniden kurar.

CPU'da ne çalışır

CPU şunları yapar:

  • başlangıçta shader derlemesi,
  • ön ayarlar, yapılandırma ve React arayüzü,
  • app-profile'ler için ön plan penceresi izleme,
  • uygulama üzerinden parlaklığı değiştirdiğinde DDC/CI komutları.

CPU ekran içeriğini görmez. Frame'ler her zaman GPU belleğinde kalır.

Performans bütçesi

Orta seviye bir GPU'da 1440p / 144 Hz için temsili bir ölçüm:

AşamaFrame başına maliyet
Yakalama~ 0,4 ms
Model~ 0,3 ms
Composite~ 0,5 ms
Toplam~ 1,2 ms

Bu, 16,6 ms / 60 Hz bütçesinin %7'sidir, ancak oyununun render yolunu bloke etmek yerine GPU tarafında çalışır, bu nedenle benchmark'larda gerçek zamana yansıyan etki tipik olarak %1'in altındadır. Daha yüksek çözünürlükler, daha yüksek yenileme hızları ve daha zayıf GPU'lar maliyeti ölçeklendirir; göreli şekil aynı kalır.

Bilerek dışarıda bırakılanlar

Birden fazla kez yeniden doğruladığımız birkaç tasarım kararı:

  • Hücre tabanlı zekâ katmanı yok. 32 × 32 karoları üzerinden akıl yürüten hücre tabanlı bir koruma katmanı prototiplenip terk edildi. Piksel başına modelleme fizik konusunda daha dürüsttür; karolar içerik sınırlarında merdiven artefaktları üretiyordu.
  • CPU tarafında burn-in sezgileri yok. Motor “bu bir Discord kenar çubuğu” veya “bu bir YouTube logosu” diye tanımaya çalışmaz. Tanıma kırılgandır ve kötü yaşlanır. Maruziyet evrensel fiziksel niceliktir.
  • Telemetri boru hattı yok. Piksel başına histogramlar asla makineni terk etmez. Tasarım gereği, bunları alan sunucularımız yoktur.

Motoru hareket halinde görmek istersen, masaüstü uygulamasındaki Gelişmiş motor sayfası canlı sınıflandırıcıyı, ayar başına otomatik denetleyici izlerini ve canlı sinyal şeridini 60 Hz'de gösterir.

KurulumKoruma Modları