DRSTool Linux üzerinde NVIDIA GPU optimizasyon aracı

Linux'ta boyle bir aracın ekliği bulunduığundan dolayı yapay zekâ yardımıyla NVIDIA gpuları için bir optimizasyon aracı geliştiriyorum. Kod MİT lisanslı ve anonimdir haliyle konumun da reklam amacıyla açılşmış olması mantıksal olarak imkansızdır, isteyuen herkes kodu alıp kullanıp* kapatıp lisanslayabilir ve satabilir. Disclaimer'dan sonra asıl konuya geliyorum. Programımız DRSTool Windows uzerindeki NVIDIA profile instector programının bir klonu olarak geliştirilmeye başlanmış ancak proje ileledikçe daha çok Linux ağırlıklı topiclerle bağdaşan bir yapı haline donuşmuştur. Vereceğim ekran goruntulerinden anlayacağınız gibi NPI'nin özelliklerine benzer özellikler taşımaktadır. DLSS Preset'i OpenGL seçenekleri ve AA davranışları gibi özel NVIDIA GPU sürücü konseptlerini kontrol etmek ve bunların konfigurasyonunu içeren bir env satırı hazırlamak gibi bir amacı var. Gelelim ekstra özelliklere VKD3D-Proton ve DXVK ile ilgili bir kısım eklenmiş ve genel geçer ortam değişkenlerine destek verilmiştir. Mesela VKD3D_CONFIG= değişkeni için mevcut gizli değişkenler ve faydaları listelenmiştir, istediğinizi kullanabilir ve çalışmayan oyunlarınızı Tweak edebilirsiniz. Ayrıca ek proje vk-flip-meter aracı da pakete eklenmiştir bu C++ programcığının amacı RTX 4000 serisinde (oncelikli larak diğer serilerde de kullanılabilir) software flip-mtering fonksiyonu bulunmadığı için multi frame generation özelliği zorla açıldığında bazı oyunlarda oluşan stuttering problemlerini çözmektir. Kullanımı biraz meşakkatli ancak ogrenildiğinde oyunlardaki stutterları ve jitterları azaltmakta işe yarayan bir programcıktır. Tek ihtiyacı olan guncel bir NVIDIA kartıdır (GTX1000+). Programcıktaki DXVK-NVAPI-GPU-Arch değişkeniyle ekran kartınızı başka bir jenerasyon olarak spoof edebilir ve eger kullanmak istediğiniz crippled bir teknoloji ise (mesela 4000 serisinde MFG'nin zorla kapatılması gibi) resmi olmayan bir şekilde açarak kullanabilmenizi amaçlamıştır. Aşağıda verdiğim oyun ekran goruntulerinde ama MFG`nin zorlanarak açılabildiğini kanıtlamak ve vk-flip-meter uygulamasının frametime grafiğini nasıl etkilediğini gostermektir. Sorularınıza açığım. Isteyen programı kopyalayıp kaynagını kapatabilir satabilir veya forklayabilir.

The Shorekeeper dedi:

Her kurulumdan sonra NVIDIA için ayar yaparken hangi ortam değişkenleri vardı diye araştırma yapmak can sıkıcı olmaya başlamıştı. Güzel duruyor. Bir sonraki kurulum senaryosunda deneyeceğim. Elinize sağlık.

Genişletmek için tıkla...

Küçültmek için tıkla...

Aynen ben de aynı sebepten kendim için yaptım bu uygulamayı, birilerinin daha işine yaradığını gormek çok güzel. Zaten NVIDIA kartı olup bundan faydalanamayan varsa, durum sandıgımızdan daha vahim demektir.

Bunle uygulama vk-flip-meter ile optimizasyon guide`ini da bırakayım buraya belki kullanmak isteyen ama kullanamayanlar vardır.

FLM_TARGET_FPS — hedef FPS
Ne yapıyor: 0 verirsen limiter tamamen pasif kalır, pacer "doğal cadence" moduna geçer — yani hedef FPS'i kendi ölçtüğü slot ortalamasından (slot_mean_ns) türetir, senin bir sayı vermene gerek kalmaz. >0 verirsen hem limiter modunda hedefe kilitlenir hem de PACER modunda GPU-bound bekçisinin (guard) referans noktası olur.
Nasıl tweak edilir:

Sadece cadence düzeltmek istiyorsan (stutter azaltma, FPS cap değil): FLM_TARGET_FPS=0 bırak, FLM_MODE=present kullan. Pacer kendi ölçtüğü aralığı uniform hale getirir, sen bir sayı zorlamamış olursun.
Sabit FPS cap istiyorsan (ör. termal/pil tasarrufu, ya da MFG çıkışını belirli bir tavana oturtmak): gerçek hedefin biraz altına ayarla, çünkü kod over_target_run'da slot ortalaması hedefin %105'ini geçerse pacing'i tamamen kapatıyor (GPU-bound guard). Yani FLM_TARGET_FPS=60 verip GPU zaten 58-59 civarına düşük performans veriyorsa guard devreye girip pacing'i söndürür — bu istediğin davranış (gereksiz yere pacing dayatmıyor).
Not: [0,1000] clamp var, aşırı değer girmeye çalışma, sessizce sınırlanır.

FLM_PACE_POINT — pacing'in uygulandığı Vulkan çağrısı
Kod üç yol tanımlıyor: PRESENT, ACQUIRE, BOTH. Gate mantığı çok net: PRESENT/BOTH present kapısında, ACQUIRE/BOTH acquire kapısında çalışıyor.
Nasıl tweak edilir:

present (varsayılan): Çoğu durumda doğru seçim. Present anında gate uygulanır, present ID/wait mekanizmasıyla en doğru flip tahminini kullanır.
acquire: Motor vkAcquireNextImageKHR'da bekleme yapıp present'i hemen ardından çağırıyorsa (yani "acquire-bound" bir render loop), pacing'i acquire noktasında uygulamak daha erken ve daha az jitter'lı bir kapı verir. Bazı Unreal/Unity Vulkan backend'lerinde bu daha stabil sonuç verir.
both: Her iki noktada da kapı — deneysel, genelde önerilmez çünkü çifte gecikme riski var; sadece motor davranışı çok tuhafsa (ör. acquire ve present arasında büyük CPU işi varsa) dene, CSV'de interval stddev'e bak, kötüleşirse geri al.
Pratik tweak yöntemi: present ile başla → CSV al → stddev/p99 yüksekse acquire'a geç → tekrar CSV al → kıyasla.

FLM_PRESENT_LEAD_NS — flip'ten ne kadar önce present çağrılsın
Kod: lead = min(FLM_PRESENT_LEAD_NS, iv/2) — yani lead değerin ne olursa olsun frame aralığının yarısını asla geçemez. Bu, yüksek FPS'te (kısa iv) yüksek lead vermenin no-op olmasını engelliyor (FIX-24'te açıklanan bug tam bu).
Nasıl tweak edilir:

Yüksek refresh rate (144Hz+, iv≈6.9ms): Varsayılan 1ms genelde yeterli. Lead'i çok yükseltmenin (>iv/2) anlamı yok, otomatik kırpılıyor.
Düşük refresh rate (60Hz, iv≈16.6ms) + GPU present'e uzun süre harcıyor (compositor/driver overhead yüksek): Lead'i 2-3ms'e çıkarmayı dene (FLM_PRESENT_LEAD_NS=2500000 gibi), flip'e daha erken present çağırıp gerçek sunum zamanını flip'e daha yakın hizalarsın.
Tweak yöntemi: CSV'de pacing sütunundaki gerçek flip zamanlarının hedefe göre sistematik gecikme/erken kalma paterni varsa (sürekli aynı yönde sapma), lead'i o yöne göre ayarla. SIGUSR1 hot-reload ile canlı deneyebilirsin, restart gerekmiyor.

FLM_SPIN_NS — son N ns'de busy-wait
Mekanizma net: clock_nanosleep ile kaba kısmı uyur, kalan spin_ns kadarını _mm_pause ile aktif spin yapar (kernel wake-up jitter'ından kaçınmak için).
Nasıl tweak edilir — CPU/hassasiyet trade-off'u:

0: Tamamen sleep, minimum CPU kullanımı ama clock_nanosleep uyandırma jitter'ı (genelde birkaç 10-100µs) pacing hassasiyetine karışır. Güç tasarrufu öncelikliyse (laptop pil modu, arka planda düşük öncelikli oyun) bunu kullan.
Varsayılan (150000 ns = 150µs): Dengeli varsayılan, çoğu masaüstü sistemde iyi çalışır.
Daha yüksek (ör. 300-500µs): Sistemin scheduler jitter'ı yüksekse (yoğun arka plan yükü, cgroup/container overhead, ryzenadj/güç yönetimi geçişleri sırasında — senin durumunda muhtemelen ilgili olabilir) spin'i artırmak daha deterministik present zamanı verir, ama bir çekirdek sürekli %100'e yakın meşgul olur.
Düşük (20000 ns = 20µs, README'deki örnek gibi): Az CPU harcamak istiyorsan ama tam sleep de istemiyorsan orta yol.
Sınır: [0, 2ms] clamp'li, üstüne çıkamazsın.
Tweak yöntemi: htop'ta ölçüm thread'inin (measure thread, cores-2'e affinity'li) CPU kullanımını izle; CSV'deki interval stddev'i spin değerine karşı grafikle — spin arttıkça stddev düşüyorsa ama CPU maliyeti kabul edilemezse ortasını bul.

FLM_DRIFT_TOLERANCE_NS — soft-slew drift toleransı
Kod: 0 verirsen otomatik clamp(iv/4, 1ms, 4ms) hesaplanıyor. Drift bu toleransı aşarsa (drift < -tol), hedef zamanı sekizde biri kadar yumuşakça öne çekiyor (limiter_next_ns -= drift/8) — yani ani faz sıçraması yerine ~8 karede kademeli düzeltme.
Nasıl tweak edilir:

Varsayılan (0 = otomatik) çoğu durumda doğru. Elle dokunmana nadiren gerek var.
Sık sık küçük drift'ler görüyorsan ve pacing "gevşek" hissediyorsa (CSV'de interval'lerin hedefin etrafında yavaş salınım yaptığını görüyorsan): toleransı düşür (ör. 500000 = 0.5ms) — daha agresif/hızlı düzeltme, ama çok düşürürsen küçük doğal jitter'ı bile "drift" sayıp gereksiz düzeltme yapmaya başlar (aşırı-tepki riski).
Sistem genel olarak gürültülüyse (arka plan yükü, thermal throttling geçişleri): toleransı artır (ör. 3000000 = 3ms) — küçük gürültüye tepki vermez, sadece gerçek kaymalarda düzeltir.
Not: drift < -2*iv || drift > 4*iv durumunda zaten hard-rebase oluyor (stall/clock jump), tolerans sadece bunun altındaki küçük sapmalar için geçerli.

FLM_MFG_MULTIPLIER — MFG çarpanı
Kod: 0 = otomatik algılama aktif (bir tespit penceresi boyunca interval < 0.7*slot_mean olan kare oranına bakarak m'yi tahmin eder: mhat = round(1/(1-p)), [1,4] clamp). >0 verirsen bu otomasyonu tamamen devre dışı bırakıp çarpanı sabitliyor.
Nasıl tweak edilir:

DLSS/FSR Frame Generation kapalıysa veya sadece 2x kullanıyorsan: 0 (otomatik) bırak, genelde doğru tespit eder.
Otomatik algılama kararsızsa (loglarda sık sık MFG carpani: X -> Y mesajları görüyorsan, yani sürekli salınıyor): bunun en olası nedeni gate'in kendi ürettiği uniform aralıkların tespiti "zehirlemesi" — kod bunun için gate_hot penceresini sıfırlıyor ama yine de nadir durumlarda kararsız kalabilir. Bu durumda bildiğin gerçek çarpanı elle gir: 2x MFG için FLM_MFG_MULTIPLIER=2, 3x için 3, 4x için 4.
MFG kullanmıyorsan (native frame'ler): FLM_MFG_MULTIPLIER=1 vererek algılamayı tamamen kapatabilirsin, gereksiz hesaplama/log gürültüsünden kaçınırsın.

Genel tweak metodolojisi

Baseline al: FLM_MODE=off FLM_CSV=/tmp/off.csv
Varsayılanlarla dene: FLM_MODE=present FLM_STATS=1 FLM_CSV=/tmp/on.csv
FLM_CONFIG=/tmp/flm.conf ile başlat, oyun içinde echo 'FLM_XXX=değer' > /tmp/flm.conf && kill -SIGUSR1 $(pgrep oyun) ile canlı iterasyon yap — her denemede restart gerekmez.
CSV'deki interval_ns stddev'i ve p99'u karşılaştır; is_hitch/is_fake oranına bak (çok yüksekse tespit parametreleri sorunlu olabilir).
Tek seferde tek parametre değiştir, aksi halde hangi değişikliğin etkisi ayırt edilemez.

Programa yeni Update pushladım yeni opsiyonlar eklendi. Programın kullanım stratejisi Quality > Quantity olmalı yani bilip bilmediğiniz her şeyi açarak bir kazanım sağlayamazsınız her oyun için kazanç sağlayan ayarlar farklı profil sistemini bu yüzden implemente ettim. Konfigurasyonlarınızı olabildiğince sade yaparsanız kazancınızı maksimize edersiniz. Ayrıca vk-flip-meter Tool'u hakkında soylemem gereken bir şey var stuttering, MFG senaryolarında ust duzeye cıktıgı için geliştirildi ancak MFG kullanılmayan senaryolarda da stutterı azaltmak %1 degerleri arttırmak için kullanılabilir. Yukarıda kullanımı bıraktım. İlgi gosteren herkese teşekkürler.