teljesítmény

kami911 képe

Lenyűgöző sebességnövekedés lesz az AMD és Intel Vulkan illesztőprogramokban

Kezdetben a Linux-on futó grafikai programok képkocka-sebessége sajnálatosan alacsony volt, a más rendszereken futó azonos alkalmazásokkal összevetve. Az utóbbi évek gyártói és Valve, illetve RedHat mérnökeinek kitartó és áldozatos munkájának köszönhetően a Linux-on futó játétkok képkocka-sebessége drasztikusan megemelkedett. Egyre jobb illesztőprogramok, egyre jobb hibakeresési eszközök, mind a program futását tekintve, mind a GPU-ban végzett feladatok optimális irányba mozdultak el. Ennek megfelelően ma már sokkal jobb játszani Linux-on, mint eddig bármikor. Mindezek lehetőséget adtak a Valve számára is, hogy másodjára – ismét – megpróbáljanak bekerülni a konzolos üzletbe egy dedikált eszközzel – a Steam Deck-kel. Úgy tűnik ez a második próbálkozás már sikeresnek tekinthető, hiszen a Steam Deck elég jól fogy és a vásárlói fogadtatása is nagyon pozitív.

A további fejlődés azonban nem várt helyről, a Zink Mesa illesztőprogram felől érkezett. A Zink, amely a OpenGL programok futtatását teszi lehetővé Vulkan-on, fejlesztésével kapcsolatban készítette Mike Blumenkrantz a vkoverhead programot. A vkoverhead egy eszköz a Vulkan-illesztőprogramok CPU-overheadjének kiértékelésére. Mike úgy találta, hogy a RADV meghajtó lassabb volt, mint az AMDGPU-PRO meghajtó a nagyon egyszerű rajzolási tesztnél. A legalapvetőbb Vulkan-teszt esetében a RADV csak körülbelül 28,3 millió rajzolást ért el másodpercenként, míg az AMDGPU-PRO körülbelül 32,8 millió rajzolást másodpercenként.

Nos, a RADV végrehajtásának profilozásával erre a nagyon egyszerű Vulkan-tesztre, és a szűk keresztmetszetek megtalálásával, amikkel foglalkozni kellett, mire befejezte kis kalandját, már 44 millió rajzolást ért el másodpercenként a RADV illesztőprogrammal. Ez 55%-os növekedést jelent a RADV rajzolási teljesítményében a mainline Mesa jelenlegi RADV kódjához képest, és körülbelül 30%-os előny az AMDGPU-PRO AMD saját Vulkan meghajtójához képest.

Ezek után figyelmét az Intel ANV illesztőprogramja felé fordította, ahol hasonló fejlesztéseket eszközöl. Ennek eredménye hozzávetőlegesen 60 százalékos javulás ebben az illesztőprogramban.

kami911 képe

Mesa RADV Illesztőprogram: Vulkan 1.3 támogatás régi AMD GFX6/GFX7 GPU-khoz

Az AMD régebbi GFX6 és GFX7 architektúrájú grafikus processzorai mostantól ellenőrzött Vulkan 1.3 támogatást kapnak a Linux rendszerekhez készült nyílt forráskódú Mesa RADV driver által, mely fejlesztést a Khronos Group is elismert.

kami911 képe

Linus Torvalds új kerneljavítása 2,6%-os teljesítményjavulást eredményez

Linus Torvalds, a Linux megalkotója nemrégiben egy kisebb javítást integrált a kernelbe, amely jelentős, 2,6%-os teljesítményjavulást eredményezett az Intel "will it scale" tesztjében. A frissítés alapját a Spectre sebezhetőség elleni védelem optimalizálása adta.

kami911 képe

Jelentős teljesítményjavulás a RADV driverben az AMD FSR2-vel

A Valve mérnöke, Samuel Pitoiset jelentős teljesítménynövekedést ért el a Mesa RADV driver számára az AMD FidelityFX Super Resolution 2 (FSR2) használatakor. Ezzel a frissítéssel a nyílt forráskódú RADV driver lényegesen hatékonyabbá vált, és közelebb került az AMD hivatalos Vulkan driverének teljesítményéhez.

kami911 képe

CIFS teljesítménynövelés és egyedi objektumok kezelése

Új javítások érkeznek a Linux NETFS kódjához, amelyek a CIFS (Common Internet File System) teljesítményének javítását célozzák, valamint egyedi, egylépéses műveletként kezelhető objektumok támogatását vezetik be. A fejlesztések célja, hogy hatékonyabb olvasási teljesítményt biztosítsanak és minimalizálják az esetleges inkonzisztenciákat.

kami911 képe

Az NVIDIA nyílt forráskódú Linux kernelmeghajtója már szinte egálban van

Az NVIDIA legújabb, nyílt forráskódú Linux kernelmeghajtója mostanra olyan fejlett, hogy a teljesítménye már megegyezik a zárt forráskódú meghajtóval. A cikk bemutatja az új fejlesztéseket, amelyek a Turing és újabb GPU-k esetében a nyílt forráskódú modult alapértelmezetté teszik, miközben továbbra is biztosítják a teljesítményt és az energiahatékonyságot.

kami911 képe

Felmosatja a padlót az AMD ZEN 4 alapú processzora az Apple M2-vel

Az AMD új, 7-es szériájú mobil processzorai nagyon jóra sikerültek. Kiemelkedőek lettek az ultramobil – „U” jelölésű CPU-k is, amelyet a cég az Apple M2 ellen vet be. Sajnos egyelőre nem túl sok rá épülő laptopot lehet kapni (ASUS Zenbook S 13 OLED, Lenovo Yoga Slim 6, HP EliteBook 845 G10 laptop és a tesztben is szereplő Acer Swift Edge 16, majd későbbiekben jön olyan jól szerelhető, moduláris laptop termék is, amely a Framework nevű gyártó terméke: a Framework 13 és Framework 16), de a megjelent tesztek alapján érdemes rájuk várni. A tesztelt processzor a 7840-es, amelyből a 7-es a legújabb generációt jelöli, a 8-as a most elérhető legmagasabb teljesítményt, az adott fogyasztási osztályban. Az U jelölés a 15-30 watt fogyasztású CPU-k jelzése, míg a 40-es szám a legújabb generációs ZEN 4 CPU architektúrát és a legfrissebb RDNA3-as GPU architektúrát jelöli. Érdekes módon az AMD jelzésrendszere nem egyértelmű ebben a tekintetben. A legfejlettebb összetevőket a 7x40-es jelzés rejti Zen 4 magokkal és RDNA3 GPU-val, míg a 7x45 a és a 7x35 processzorok mellé 2 darab RDNA2 alapú GPU számítás egységet csomagol a sorrendben a Zen 4, illetve a Zen 3+ CPU magok mellé. Így ez utóbbiak, kizárólag külső dVGA megoldás mellett szállítanak majd a játékban is megfelelő grafikus teljesítményt.

kami911 képe

Landolt a Linux 6.0-ban a „Dummy Wait” problémát javító AMD sebességnövelő javítás

2002 óta, amikor a kernel ACPI-támogatással bővült, egy felesleges várakozási - „dummy wait” művelet került be a kernelbe. Történt ez mindazért, mert akkoriban néhány chipkészletnél az STPCLK# nem volt időben érvényesítve a kernelben az üresjárat során. A dummy I/O olvasás késlelteti a további utasításfeldolgozást, amíg a CPU teljesen le nem áll. Az AMD egyik mérnöke azonban nemrégiben észrevette, hogy ezt a viselkedést a modern AMD Zen 3 hardvereken is alkalmazzák, és megállapította, hogy ez teljesítményproblémákhoz vezethet az terhelt és üresjárati fázisok között gyorsan váltó munkaterheléseknél, és különösen a nagyobb magszámú rendszerek, például a Ryzen Threadripper és EPYC platformok esetében.

K Prateek Nayak, az AMD mérnöke, kimutatta, hogy a hibás megoldása milyen jelentős hatással lehet a teljesítményre a modern hardverekre az AMD rendszereken. Az Intel CPU-k eközben nem használják ezt a kódutat a modern hardverekhez, így nem érinti őket ez a teljesítményvesztés. Az adott tesztben a minimum adatátviteli értékek 1390.52 százalékkal növekedtek és az átlagos adatátvitel is 50.85 százalékkal emelkedett.

Eredetileg az AMD egy javítást végzett itt, majd Dave Hansen, az Intel mérnöke tisztította és egyszerűsítette ezt a kódot. Ez utóbbi javítás egyszerűen nem alkalmazza ezt a "dummy wait" megoldást, kivéve a régebbi (Nehalem előtti) Intel rendszereket. Mostantól tehát az AMD rendszerek is kihagyják ezt a műveletet, amely a modern rendszereken ronthatja a teljesítményt. Mivel ez főként az leterhelt és az üresjárati állapotok között gyakran váltó munkaterhelésekre van hatással, valamint a nagyobb magszámú rendszereknél jobban észrevehető, az AMD EPYC szerver teljesítménye ezzel a javítással meglehetősen érdekes lehet, különösen a webszerver / adatbázis-munkaterhelések és más típusú gyors tesztek esetében.

kami911 képe

Itt a GameMode 1.7

A GameMode, a Feral Interactive rendszeroptimalizáló eszköze nemrég egy új kis kiadást kapott.

Mit csinál? Amikor játékokat futtat vele, az eszköz olyan dolgokat tud csinálni, mint például a CPU-vezérlés teljesítményének beállítása, az I/O prioritás, a processzek nice értéke, a kernel scheduler megváltoztatása, a képernyővédő kikapcsolása, a GPU teljesítmény üzemmódba állítása, egyéni szkriptek engedélyezése és így tovább. A lényeg, hogy sok esetben biztosíthatja, hogy a lehető legnagyobb teljesítményt adjuk egy játéknak, ha éppen sikerül.

Feliratkozás RSS - teljesítmény csatornájára