Czy to normalne, że gra używa 100% procesora?

23

Właśnie zaimplementowałem obsługę wielowątkowego wprowadzania danych w silniku gry, w którym kod odpytujący system operacyjny w celu zebrania danych wejściowych i znaczników czasu znajduje się w osobnym wątku, a każda ramka w głównym wątku zjadam zebrane dane wejściowe do logiczny czas gry. Wszystko działa, ale ta konfiguracja zużywa 100% mojego procesora. Mam dwa rdzenie i nawet do 100% podczas działania mojej gry.

Sprawdziłem w innych grach, czy one też to robią. Na przykład Skyrim i Doom 3 wydają się być w porządku z nieco ponad 60% procesorem.

Czy jest dopuszczalne, aby gra wykorzystująca wielowątkowe dane wejściowe wykorzystywała 100% procesora? Jeśli nie, jakie sztuczki wykorzystują takie gry, aby zmniejszyć zużycie procesora przez wątek wejściowy?

The Light Spark
źródło
7
Więc co powiesz, w zasadzie masz wątek z nieskończoną pętlą while, która stale odpytuje system operacyjny pod kątem nowych zdarzeń? while true do CheckForEvents;
Kromster mówi o wsparciu Moniki
5
Jeśli aplikacja zużywa 100% czasu procesora bez względu na użycie i szybkość procesora, można to słusznie uznać za błąd. Nie należy używać więcej czasu procesora niż jest to potrzebne do renderowania ramki na cykl odświeżania monitora.
kasperd
3
@TheLightSpark Czy wątek wyborczy nawet nie śpi? Jeśli ciągle zapętlasz i sprawdzasz bez snu, prawdopodobnie zjesz o wiele więcej czasu procesora, niż to konieczne.
Łukasz
3
Re @Luke: Nawet spanie tylko o milisekundę między ankietami drastycznie zmniejszy użycie procesora. Jakiś czas temu napisałem GUI dla narzędzia wiersza poleceń, które pobierało plik wejściowy i tworzyło plik wyjściowy mniej więcej tego samego rozmiaru. Aby oszacować procent, odczytałem rozmiar pliku wyjściowego i zaktualizowałem pasek postępu (używając while (true)). Wykorzystano do tego 90% + jednego procesora. Dodano Thread.Sleep(5)do tego obniżenie zużycia procesora do poniżej 40%. Dochodzenie do 25 milisekund między badaniami obniżyło go do poziomu poniżej 10%.
Cole Johnson
2
@AlecTeal Myślę, że nie zwróciłeś wystarczającej uwagi na to, co powiedziałem. Renderowanie lepszej grafiki nie jest tym samym zastosowaniem, a oczywiście włączenie lepszej grafiki zwiększy zużycie procesora. Ale jeśli przejście na szybszy procesor spowodowałoby, że Twój kod spędziłby więcej cykli, generując dokładnie ten sam wynik, kod jest wadliwy. Automatyczne mierzenie jakości grafiki, którą można renderować za pomocą konkretnego procesora, jest rozsądnym ustawieniem domyślnym. Ale powinieneś pozwolić użytkownikom na wybór, jeśli są zasilani z baterii lub potrzebują procesora do zadań w tle.
kasperd

Odpowiedzi:

41

Tak, jest to normalne, aby wypróbować grę w czasie rzeczywistym użyć 100% procesora, aby działać tak szybko i dobrze, jak to możliwe. Tak, aby gracz widział tyle klatek na sekundę lub tak dobrą symulację fizyki, albo cokolwiek innego, co może zapewnić jego komputer.

W twoim przypadku - Nie, wygląda to na nieefektywny projekt, aby wziąć wątek i sprawić, by sondował w poszukiwaniu zdarzeń w pętli (while true do CheckForEvents; ). Popraw mnie, jeśli się mylę, ale system operacyjny już odpytuje zdarzenia. Powinieneś po prostu sprawdzić je z głównego wątku raz na każdy tik.

Główna pętla gry powinna być wystarczająco szybka, aby działać z prędkością ponad 30 tyknięć na sekundę, co wystarcza do wykonywania poleceń odpytywania w wielu grach. Gracz nie zobaczy różnicy, jeśli jego polecenia zostaną przetworzone, np. 0-33 ms później. Z drugiej strony możesz użyć tego dodatkowego rdzenia procesora do bardziej korzystnych zadań, takich jak DUŻO lepsza sztuczna inteligencja, fizyka czy cokolwiek innego.

PS Zgodnie z prośbą o wyjaśnienie w komentarzach, nie należy ślepo przyjmować powyższych liczb dla wszystkich rodzajów gier. Podczas gdy gra TBS może wymagać tylko 1 tyknięcia na turę, a gra RTS może być w porządku z 10 tyknięciami na turę, inne gatunki, takie jak RaceSims, potrzebują znacznie więcej. I oczywiście nie łącz logicznych znaczników z szybkością klatek, są to dwie osobne rzeczy.

Kromster mówi, że popiera Monikę
źródło
5
Głosowałbym za tym pytaniem, ale potem widzę, że polecasz 30 tyknięć na sekundę. IMHO (i wielu innych graczy) powinieneś dążyć do 60 tyknięć (a więc 60 klatek) na sekundę. 60 FPS dla wielu osób wygląda bardziej płynnie, gra bardziej responsywnie i rzadziej wywołuje pewną grupę użytkowników z chorobą lokomocyjną.
Nzall,
4
Opóźnienie wejściowe 33 ms jest bardzo zauważalne ...
Synxis,
1
@NateKerkhofs: Pochodzę z RTS, gdzie 10 tyknięć jest zwykle. To szeroki świat, dodam o tym szczegóły. Dzięki za wskazanie.
Kromster mówi o wsparciu Moniki
1
@KromStern: Nie mogę w pełni mówić za Nate'em, ale trzeci akapit można interpretować jako „30 Hz powinien być twoim celem”, chociaż można go również interpretować jako „30 Hz to minimum, które możesz tolerować” (co może być tym, co miałeś na myśli) ).
Sean Middleditch,
1
Używanie 100% procesora to straszna praktyka. Przekręcasz użytkowników laptopów na rzeczy, które w żaden sposób, w kształcie ani formie nie wymagają użycia 100% procesora. Zakoduj odpowiednią pętlę gry, która może skutecznie przesyłać klatki do monitora.
Chris Dennett
9

Gra ze stałym aktywnym odświeżaniem okna będzie przeważnie uruchamiana w trybie pełnoekranowym i będzie jedynym (dużym) programem komputera zarządzanym przez system operacyjny. Jest więc całkowicie dopuszczalne użycie 100% procesora, ponieważ nic innego nie powinno go potrzebować.

Nie oznacza to jednak , że musisz zawsze używać 100% niezależnie od stanu gry. Większość pętli gier wykorzystuje metodę uśpienia jako ogranicznik klatek, jeśli zakończyły renderować klatkę przed limitem liczby klatek na sekundę, aby procesor nie był wykorzystywany do niczego.
Prawdopodobnie tak dzieje się w twoich przykładach: twoja maszyna jest szybsza niż Skyrim lub Doom 3 muszą uruchomić, więc używają tylko tego, czego potrzebują - ale wszystkiego, czego potrzebują.

Jak powiedział @KromSterm, system operacyjny zwykle już odpytuje zdarzenia, więc nie ma potrzeby wykonywania pętli szybciej niż system operacyjny. Jeśli masz tylko dwa rdzenie, użycie 100% drugiego tylko do wykrywania zdarzeń nie jest dobrym pomysłem, ponieważ jeśli przenosisz tylko zdarzenia do głównej pętli aktualizacji, jest to bardzo szybkie wykonanie. Powinieneś spróbować użyć tego rdzenia dla części głównego zadania wątku zamiast innego wątku.

Araktor
źródło
„użyj metody snu” - czy mam rację sądząc, że jest to znane jako ogranicznik klatek na sekundę?
Gusdor,
3
tryb uśpienia nie jest dokładną metodą ograniczania klatek, jeśli celem jest ograniczenie klatek do monitorowania częstotliwości odświeżania, wówczas lepiej jest zastosować vsync obsługiwaną sprzętowo (lub g-sync nvidii, jeśli jest dostępna)
Sarge Borsch
8

Istnieje kilka wad dążenia do wykorzystania całego dostępnego czasu procesora w komputerze lub grze mobilnej.

Wymagania systemowe: jeśli gra jest dostępna na komputerze, na którym ją rozwijasz, może nie być dostępna na słabszym komputerze należącym do osoby, która ją kupiła. Ograniczenie użycia procesora sprawi, że gra będzie nadawała się do użytku na komputerach, które mogą już mieć więcej osób. Jeśli naprawdę chcesz sprawdzić, czy ograniczasz swój rynek, przetestuj swoje gry komputerowe i gry konkurencji na odłączanym zasilaniu Atom, takim jak Transformer Book, lub przetestuj gry mobilne na niedrogim telefonie z systemem Android.

Zużycie energii: laptop szybciej rozładowuje baterię, gdy cztery rdzenie są używane na 100 procentach pełnej częstotliwości niż, powiedzmy, dwa rdzenie na 60 procentach połowy częstotliwości. Upewnij się więc, że wątek odpytywania kontrolera, wątek AI, wątek fizyki i wątek graficzny są zablokowane, dopóki nie nadejdzie czas ich ponownego uruchomienia. Z wyjątkiem kilku bardzo niespokojnych gatunków, takich jak walka i rytm, nie musisz sondować kontrolerów szybciej niż około 60 Hz, więc ustaw wątek odpytywania na czas 60 Hz.

Zmienność fizyki: jeśli fizyka wpływająca na rozgrywkę jest bardziej szczegółowa na mocniejszych maszynach, to samo działanie gracza będzie miało różne wyniki na różnych maszynach. Oznacza to, że gracz może oszukiwać za pomocą silniejszej lub słabszej maszyny. Id's Quake III Arena słynie z tego, że częstotliwość klatek wpływa na wysokość skoku . Aby tego uniknąć, wiele gier używa fizyki w ustalonym czasie. Ale to nie wpływa na fizykę, która nie jest związana z rozgrywką, taką jak efekty cząsteczkowe lub efekty tkaniny lub interpolacja współrzędnych między klatkami fizyki w celu renderowania wideo z większą częstotliwością klatek niż fizyka. Więc zaprojektuj swoją fizykę za pomocą jakiegoś wariantu kontrolera widoku modelu architektura, w której podstawowe rzeczy (przyspieszenie, wykrywanie trafień itp.) idą w modelu, a regulowane cukierki do oczu idą w polu widzenia.

Zmienność AI: jeśli AI jest bardziej szczegółowa na silniejszych maszynach, wrogowie będą zachowywać się inaczej na różnych maszynach. Na przykład w implementacji Go lub Chess przeciwnik będzie słabszy na słabszym komputerze, a gracze mogą oszukiwać, grając w grę na słabszym komputerze lub uruchamiając procesy w tle, takie jak antywirus lub transkodowanie wideo lub aktualizacje systemu operacyjnego.

Damian Yerrick
źródło
4
+1 za zużycie energii. Zwłaszcza, że ​​należy wziąć pod uwagę branżę telefonów i tabletów, gdzie jest to niezwykle ważne.
akaltar
1
Zużycie energii wpływa również na hałas, nawet na komputerach stacjonarnych. Współczesne komputery stacjonarne często spowalniają wentylatory, gdy system jest chłodny. Być może użytkownik koduje wideo (o niskim priorytecie) podczas odtwarzania, więc nie marnujesz wolnego czasu procesora. Lub dla odtwarzaczy przesyłających strumieniowo transmisje, które pozostawiają więcej cykli do kodowania wideo, to wielka sprawa i umożliwia wyższą jakość wideo. (kodowanie wideo jest trójdrożny kompromis między czasu procesora, bitrate i jakości, tak więcej środków czasu procesora w czasie rzeczywistym kodujący w wyższej jakości w tym samym bitrate.)
Peter Cordes
1
Zużycie energii powinno być najważniejszym czynnikiem, wszystkie inne względy drugorzędne, IMHO. Jedyne, do czego użyłbym 100% procesora (jeśli to naprawdę pomogło!) To VR.
Chris Dennett