Érdekes híresztelések kaptak szárnyra a Windows 10 Fall Creators frissítésének megjelenése után. Ennek az egyik újítása volt az új feladatkezelő, amiről az alábbi hírben részletesen beszámoltunk. Maga a funkció rendkívül hasznosnak mondható, de valljuk be, hogy a PC-kben lévő GPU-kat jelentős részben játékra használják a felhasználók, és csak azért nem fognak taszkot váltani, hogy lássák a futtatott program nagyjából pontos terhelését. Persze a GPGPU-s alkalmazásokra még így is jó az újítás, és még a játékosokat sem zavarhatja, hogy ott van, tehát a pozitív fogadtatás borítékolható volt.
Az új feladatkezelő azonban már egy nagyobb változás előszele, ugyanis jelen formájában igen korlátozott a jelentősége. Az OEM-ek számára leadott tervekben azonban feltűnik egy komolyabb strukturális változás az operációs rendszerben, ami teljesen átalakítja a GPU-k elérését. Bár még nem teljesen világos, hogy milyen háttértechnológiák kerülnek kidolgozásra, de úgy tűnik, hogy a Microsoft célja az, hogy átalakuljon a Windows által támogatott aktuális GPGPU-s modell. Utóbbi ugyanis nem túl kedvező, mivel a GPGPU-s API-k az úgynevezett kerneleket nem közvetlenül futtatják. Ezeknek tartalmaznia kell egy OS rendszerhívást is, vagyis amikor egy GPGPU-s program elindít egy kernelt, akkor valójában megkéri a Windowst, ezen belül is egy erre vonatkozó szervizfolyamatot, hogy indítsa el azt a programot futtató felhasználónak, az adott API implementációjának kernel driverén.
Az előnye ennek a modellnek, hogy működik, ezt jó ideje tapasztalhatjuk, és tulajdonképpen az operációs rendszer évek alatt kialakított alapvető struktúrájába viszonylag kis erőforrás mellett volt beilleszthető. A hátránya viszont az, hogy egy kernel elindításához gyakorlatilag az alkalmazáshoz tartozó parancslistától kezdve, a processzoron, a szükséges szervizfolyamatokon és a meghajtóimplementáción át, az operációs rendszer által vezérelt GPU-s parancslisták feltöltéséig egy rakás, a programfuttatás nézőpontjából teljesen felesleges munka történik. Ezekre leginkább azért van szükség, mert a Windows aktuális strukturális dizájnjába így volt a legegyszerűbben beilleszthető a GPGPU-s modell, hiszen nem kellett a gyártóknak egyezkedni a GPU-nak küldött csomagformátumon. Az utóbbira vonatkozó eltéréseket kezeli az operációs rendszer és az adott gyártó kernel meghajtója, gyakorlatilag valós időben lefordítják a csomagokat az hardver által emészthető formátumra, ami azért nagy baj, mert minden egyes csomag csak a CPU segítségével tölthető be a GPU-k parancslistájába.
A Microsoft ötlete annyi, hogy az egész működés legyen úgy átalakítva, hogy a fenti bekezdésben tárgyalt hátrány teljes egészében eltűnjön. Ezzel szükségtelenné válna a kernel meghajtó, a csomagfordítást elősegítő szervizfolyamat, illetve nyilván a kernelek indításához nem lenne szükség rendszerhívásra sem. Az egyetlen kritériumnak az tűnik, hogy egységesíteni kell a hardverek által kezelt csomagformátumot, ami csak első hallásra tűnik problémának. Valójában viszont még hardveres változásra sem lenne szükség, akár a mai GPU-kkal is megoldható lenne ez a feladat, ha a Microsoft előállna egy definiált specifikációval. A gyártók ugyanis leginkább azért alkalmaznak eltérő csomagformátumot, mert sosem ült össze mindenki erről tárgyalni, holott igazából semmi akadálya nincs az egységesítésnek. Leszámítva persze azt, hogy a meghajtókat módosítani kellene, de ez nyilvánvaló az új dolgokat szoftveresen támogatni kell.
Abban viszont valóban igazuk volt a gyártóknak, hogy a Windows tekintetében addig felesleges egymással diskurálni, amíg a Microsoft nem módosítja az operációs rendszer struktúráját. Erre azért van szükség, mert első hallásra ugyan kis változásnak tűnnek a rendszerhívás nélkül futtatható kernelek, a valóság azonban az, hogy rendkívül komoly munka szükséges ennek az eléréséhez. Már csak azért is, mert az operációs rendszeren belül a CPU-val azonos elérhetőségi szintre kerülnének a gyorsítók azáltal, hogy az alkalmazás a CPU segítsége nélkül is képes lenne programot futtatni rajtuk. Így már igencsak értelme lenne az új feladatkezelőnek is, persze némileg átalakított formában.
Egy ilyen modell a grafikus API-k tekintetében is egészen új lehetőségeket nyitna meg, bár valószínűleg nem ez a fő mozgatórugó, mivel az explicit API-kra még lehet pár évig építeni, ugyanakkor ezek is ugyanúgy kevesek lesznek egyszer, ahogy a korábbi, mára legacy besorolású API-k is komoly limitációkba futottak.
A nagy kérdés, hogy a strukturális reform mikor fut be a Windowsba. Erre még nincs válasz, de a Microsoft elég jól látja a problémát, noha kétségtelen tény, hogy számos alkalommal felmerült már az aktuális GPGPU-s programozási modellek rákfenéjeként, amire számos, tulajdonképpen nagyon hasonló megoldási javaslat is született. Érdekes kérdés még, hogy ha a Windows struktúrája átalakul, akkor alternatív platformok implementálhatók lesznek-e rá. Valószínűleg igen, bár nagy összegben fogadnánk arra, hogy a Microsoft a saját rendszerét fogja promotálni.
