Odpowiedzi:
Jako osoba z kilkuletnim rozwojem sterowników uważam to za dwie osobne kwestie.
Sterownik graficzny to bardzo skomplikowana bestia. Wdrożenie wszystkiego w optymalny sposób byłoby po prostu niemożliwym zadaniem; jest to wystarczająco duża przeszkoda, aby stworzyć sterownik zgodny ze specyfikacjami - a specyfikacje stają się coraz bardziej złożone. Tak więc opracowujesz sterownik na podstawie specyfikacji i kilku aplikacji testowych (ponieważ w wielu przypadkach nie ma jeszcze prawdziwego oprogramowania).
Wraz z nim pojawia się prawdziwa gra (lub test porównawczy lub inne zastosowanie dla sterownika, takie jak dekodowanie wideo), które uwidacznia wąskie gardło w sterowniku. W trakcie pracy zastanawiaj się, jak wygładzić rzeczy i przyspieszyć ten przypadek użycia. Możesz łatwo zgłosić, że gra XYZ jest szybsza o 27,3%, ale w rzeczywistości każda aplikacja, która powiedziała przypadek użycia (powiedzmy, dynamiczna aktualizacja tekstur), staje się szybsza.
Potem jest brzydka, rzeczywista optymalizacja dla poszczególnych aplikacji, w której sterownik wykrywa, która aplikacja jest uruchomiona (lub który shader jest kompilowany) i robi coś nietypowego. Było wiele upublicznionych przypadków, w których na przykład zmiana nazwy pliku wykonywalnego 3dmark nagle zmienia wyniki.
Wydaje mi się, że tego rodzaju optymalizacje to strata czasu dla wszystkich - w przypadku testów porównawczych kłamiesz swoim klientom i możesz zmienić sposób, w jaki moduł cieniujący zachowuje się w stosunku do tego, czego naprawdę chce programista. Pamiętam przypadek, w którym moduł cieniujący został zmieniony z wyszukiwania tekstur na obliczenia w module cieniującym (które działały tylko na sprzęcie wspomnianego producenta), które były bliskie, ale nie dokładnie taki sam wynik, a programista bał się, że to nie jest legalne optymalizacja.
W idealnym świecie nie zrobiliby tego.
Nie jest to jednak idealny świat, więc ulepszenia wydajności specyficzne dla gry mogą wynikać z jednego lub więcej z poniższych (nie jest to wyczerpująca lista):
Gra wykonuje kombinację operacji A, B i C z ustawionymi stanami X, Y i Z. Sterownik może przyjmować założenia w oparciu o to i spychać rzeczy na bardziej optymalną ścieżkę kodu.
Gra nigdy nie wykonuje operacji I, J ani K. Ponownie sterownik może być w stanie wybrać bardziej optymalną ścieżkę kodu w oparciu o możliwość założenia, że operacje te nigdy nie są wykonywane.
Gra robi pewne rzeczy w nieco (lub nie tak lekko) nieoptymalny sposób. Kierowca wie o tym, przechwytuje połączenia i konwertuje je na coś (mam nadzieję!) Odpowiednik, który będzie z nim działał lepiej.
Można dokonać kompromisów specyficznych dla gry; np. jest OK, jeśli ta kombinacja stanów renderowania działa wolno, ponieważ ważniejsze jest, aby ta kombinacja przebiegała szybciej, więc zoptymalizujmy ją odpowiednio.
Należy tutaj zauważyć, że żadne z nich nie powinno być „wymagane”. Dopóki zarówno sterownik, jak i interfejs API gry są zgodne, wszystko powinno działać. Ale czasami kompromisy w szczególnych przypadkach, aby uzyskać maksymalną wydajność, mogą być uważane za właściwe. Powstrzymam się od komentowania, czy to dobrze.
Twórcy gier przekraczają granice układów GPU. Możemy dokonać analogii do gry i silnika gry. Im bardziej zaawansowane są wymagania gry, tym bardziej zaawansowany musi być silnik gry, aby ją obsługiwać. To samo dotyczy kart graficznych.
Gry komputerowe i producenci GPU to dobrzy ludzie z łóżka. W ich najlepszym interesie jest współpraca w celu ulepszenia GPU, a tym samym ulepszenia gry. To klasyczni faceci oprogramowania współpracujący ze związkami facetów ze sprzętem. Obie strony mają coś do dodania, jeśli chodzi o projektowanie interfejsu między oprogramowaniem a sprzętem. Ten interfejs to sterownik.
Te aktualizacje mogą zawierać poprawki błędów, które znaleźli faceci oprogramowania, lub ulepszenia, które wprowadzili faceci sprzętowi, aby spełnić wymagania facetów oprogramowania. Ten związek znajdziesz wszędzie.
Prawdopodobnie powodem umieszczenia określonych gier w informacjach o wydaniu aktualizacji sterownika jest PR. Nie tylko pokazuje, że producent kart X będzie działał naprawdę dobrze z grą Y, ale także pokazuje, że gra Y będzie jeszcze lepsza niż wcześniej.
Możliwe, że zespół twórców gier napotkał błąd sterownika GPU, który spowodowałby, że gra nie działałaby poprawnie, gdyby błąd sterownika nie został naprawiony.
Czasami jest to także chwyt marketingowy . Na przykład ATI / AMD niedawno dołączyło kopię Dirt 3 z nowszymi procesorami graficznymi i podsunęło pomysł grania w Eyefinity z 3 monitorami w tej grze.
To trochę symbioza.
Producent GPU: Hej! Ta nowa funkcja! Nikt go nie używa!
Twórca gry: Możemy go użyć! Powiązać naszą grę ze swoim GPU, który korzysta z tej funkcji?
Sprzedawca GPU: Do diabła!
Prawda jest taka, że procesory graficzne nie wymagają sterowników specyficznych dla gry.
Sterowniki specyficzne dla gier są częścią działań marketingowych podejmowanych przez producentów GPU w celu uzyskania przewagi nad innymi producentami GPU. Jeśli potrafią wykazać się lepszą wydajnością w popularnych grach, dostosowując swoje sterowniki do konkretnych gier, to (zgodnie z teorią) przyciągają więcej graczy w tych grach.
To prawie wszystko.