- Yettel topik
- Motorola Edge 60 és Edge 60 Pro - és a vas?
- Xiaomi 15 - kicsi telefon nagy energiával
- Amazfit Active 2 NFC - jó kör
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- iOS alkalmazások
- Minden a BlackBerry telefonokról és rendszerről
- Megjelent a Poco F7, eurós ára is van már
- One mobilszolgáltatások
- Sony Xperia 1 V - kizárólag igényeseknek
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Nem függ a kettő össze. Maximum annyiban, hogy vannak kész GLSL shaderek, de a glslang-nak készül a HLSL komponense: [link]
A Vulkan leginkább azért érheti meg, mert maga az API sokkal jobban illeszkedik a slotalapú architektúrákhoz, így nem kell nagyon speciális kódot írni a GeForce-okra, mint DX12 alatt, ahol sajnos vannak játékok, ahol ezt nem teszik meg. A DX12 ebből a szempontból nagyon igényli a memóriaalapú architektúrákat, mint a GCN és a Gen9-es Intel IGP. De nyilván ha magából az API-ból hiányzik olyan képesség, ami kellene az adott programnak, akkor nem marad más választás, mint a DX12. -
Abu85
HÁZIGAZDA
Ez annyira nem igaz, hogy még a Khronos Group is tagadta. Az előző évi SIGGRAPH-on elmondták, hogy a Vulkan nem az OpenGL leváltója, hanem az új explicit irányra egy platformfüggetlen alternatíva. Ekkor még az volt a terv, hogy az OpenGL fejlődik tovább, jönnek új verziót, stb. Azóta csak kiterjesztések jöttek.
(#49) Jack@l: Nem hisszük, hanem konkrétan tudjuk: [link] - Tom Olson a Vulkan csoport vezetője itt jelentette be, hogy a Mantle-ből származik. Ezért emelte ki az AMD-t mert nélkülük ez az API nem létezne.
-
Abu85
HÁZIGAZDA
Akkor leírom, hogy az OpenGL 4.3 azért lett visszaváltva, mert az 15-20%-kal gyorsabb volt a béta kódútjánál. Az meg, hogy valakinek lassú volt egyéni probléma, mert ez függ a meghajtótól is, főleg OpenGL esetében. Ha sokkal rosszabbul ment volna az új kódút a réginél, akkor nem váltott volna vissza az ID. Már csak azért nem, mert az AMD-hez kialakított 4.3-as kódút egy kurva nagy púp a hátukon, hiszen tele van specifikus kiterjesztéssel, amihez alternatív shaderek kellenek, vagyis az egész kód menedzselése rohadt drága az ID-nek, és sokkal jobb lenne nekik, ha nem kellene szállítani, de hát gyorsabb, tehát fel kell vállalni az ezzel járó gigaszopást.
-
Abu85
HÁZIGAZDA
Azért mentek vissza, mert gyorsabb volt az AMD saját kiterjesztéseivel a kód. Nem is kevéssel. Kb. 15-20%-os különbség volt a kettő között az AMD kiterjesztései javára. Amikor ennyiféle kódutat csinál egy stúdió, akkor igazából teljesen logikus, hogy azzal a kódúttal szállítják a végleges játékot, amelyikkel a leggyorsabb az eredmény. Főleg, ha a korábbi kódút +15-20%-ot jelent. Az ID-nek ez kötelessége, hiszen ők azt akarják, hogy a lehetőségeikhez mérten minden hardveren a legjobban fusson a program.
A usereknek kb. semmi esélyük eldönteni, hogy melyik kódút a leggyorsabb, mert nincsenek meg a béta idején a megfelelő meghajtóik.Mindegyik GCN-es Radeon támogatja az OpenGL 4.5-öt. Újabb meghajtó kell hozzá.
-
Abu85
HÁZIGAZDA
Erről fentebb volt szó, és újra nincs kedvem lejátszani, mert értelmezni ezeket már nem akarod, csak fújsz az ID-re, mert az NV-re nem dolgoztak. Nem ők tehetnek róla. Dolgoznának ők, ha kapnának egy hangyafasznyi segítséget, hogy miképp kell optimalizálni ezekre a hardverekre.
(Teljesen mindegy az OpenGL verzió, mert mindegyik OpenGL kódút eltérő gyártói kiterjesztéseket használ. Az AMD-nek azért nem kell az OpenGL 4.5, mert a saját kiterjesztéseik jobbak azoknál, amik az OpenGL 4.5-be vannak építve szabványosan. Ha gyártói szinten szegmentált a kódút, akkor világos, hogy minden gyártón a legjobb kiterjesztéseket használják. Ugyanúgy tudna egyébként OpenGL 4.5-ös kódot futtatni, csak az ARB kiterjesztések lassabbak lennének AMD-n.)
-
Abu85
HÁZIGAZDA
Carmack elment és vitte magával a saját technikai csapatát. Helyére jöttek egy csomóan a Crytektől, akik már nem azt a filozófiát képviselik, amit Carmack. Ők már nem ragaszkodnak az NV-hez. Azzal a céggel dolgoznak, aki segíti a munkájukat. Ennyi. Megvuduzhatod őket érte, de így döntöttek. Az NV-nek bármikor esélye van arra, hogy teljes hátraarccal újra elkezdjék dokumentálni a hardvereket, ahogy a G80 idején tették. Ezt az ID aktuális szakemberei nem tiltják meg.
Az NV-nek egyébként nem support problémája van, hanem üzletstratégiai. Teljesen mindegy, hogy hány embert küldesz oda az ID-hez, ha egyik ember sem válaszolhat arra a kérdésre, hogy miképp működik az architektúra.[link] - ezt látja a játékos.
-
Abu85
HÁZIGAZDA
[link] - és ez lett az eredmény, amiről a leképező fejlesztője számolt be a SIGGRAPH-on. Ha a kritikus jelenetekben +60-70% nem elég, akkor ott elvárási problémák vannak. Azt pedig sajnálom, hogy GeForce-on nem hoz semmit. Nem tudom az NVIDIA-t meggyőzni arról, hogy nyissák meg az architektúrát, hogy az ID optimalizálni tudjon rá. Valószínűleg az ID próbálta győzködni őket, de ennyire futotta. Ez üzletstratégiai döntés, ami nem minden fejlesztőnek kedvez, az ID-nek nyilván nem.
-
Abu85
HÁZIGAZDA
Driver szintjén is eléggé. A Khronos oldalán ebből rengeteg vita volt, hogy OpenGL-re létezik olyan drivere az NV-nek, ami meghajtóval interakcióba lépő szoftverréteg nagyjából 90%-át leváltja. Vagyis rögtön van egy konfigurációd, amire kapásból két kódút kell, attól függően, hogy bináris vagy FOSS drivert telepítesz. Az Intelnél szerencsére csak egy implementáció van, míg az AMD-nél van már két implementáció, de a bináris nem cseréli le a disztribúcióban szállított szoftverrétegek zömét. Valamennyit ugyanakkor lecserél, tehát ehhez is két külön kódút kell.
A Vulkan annyiból jobb, hogy az egy friss start. Még nem tudtak annyi mindent szétbarmolni a gyártók, de ha nem lesz egy erős kéz, ami ebben megakadályozza őket, akkor ugyanaz lesz, mint az OpenGL-nél. Bírom Linust, hogy mutogatja a középső úját a felelősöknek, de ettől nem lesz jobb hely a Linux.
-
Abu85
HÁZIGAZDA
Az OpenGL problémája API szintű, mivel a fordításnál nincs köztes shader IR, vagyis minden gyártóra alternatív shader az ideális. Ezt például a Doom eléggé jól kezeli, mert gyártóspecifikus shadereket generál az ID tech 6 ennek a problémának a kezelésére. Emellett az OpenGL implementáció is gyártóspecifikus. Van egy az NV-nek, egy az AMD-nek és egy az Intelnek.
Ami miatt az AMD sokat gyorsult a Vulkan alatt az a shader intrinsics. Emiatt Vulkan alatt van egy szabványos implementáció mindenkinek, és egy úgynevezett gyors implementáció az AMD-nek.Az NV-n azért nem ideális a Doom, mert nehezen tudtak megfelelni a GeForce page table modelljének. Azt egyébként sosem ígérte az ID, hogy a Vulkan GeForce-on is gyorsít. Csak az AMD-n gyorsít, mert ott van olyan mélységekben dokumentálva az architektúra, hogy ebből előnyt építsenek egy programon belül.
-
Abu85
HÁZIGAZDA
A Linux eléggé külön kategória több szegmensben. A Khronos Group is úgy beszél ezekről az API-król, hogy PC-n a Windows a célplatform. A Linux a lehetőség, de annyira töredezett az egész, hogy értelmetlen abba bármekkora erőforrást is betolni, amikor maguk a gyártók és a disztribúciók fejlesztői sem tudnak megegyezni az irányokról.
Majd egyszer ráeszmélnek, hogy nem jó, amit csinálnak, és akkor eljön a Linux éve, de ez még évtizedekre van. -
Abu85
HÁZIGAZDA
Eltűnni az OpenGL sem fog. De ma már a DX9-et is teljesen leváltotta a DX11. Alig van olyan cég, aki DX9-re fejleszt célzottan.
Itt igazából az lenne a lényeges, hogy fejlődjön az API, mert ha csak áll a semmiben, akkor elmegy mellette a világ.(#31) Jack@l: A Doom esetében már nem tudom, hogy mennyiszer írtuk le, hogy az AMD előnyét a gyors kódok adják. Ez Vulkan alatt engedélyezve van, míg OpenGL alatt nincs. Ettől gyorsulnak sokat. Világos, hogy az a kód lesz a gyorsabb, ahol a préselés csak 1 utasítás és nem 64. OpenGL alatt is lehetne ennyi, de az AMD nem tette ezen az API-n ezt a képességet kihasználhatóvá.
-
Abu85
HÁZIGAZDA
Mi sem. Egy kérdőjel van a címben, és az Intel fejlesztőjének a kijelentése van elemezve.
Az OpenGL és a Vulkan megélne egymás mellett. A probléma ott kezdődik, hogy ha a Khronos minden évben csak egy-két kiterjesztést ad hozzá, akkor azzal gyakorlatilag kivégzik az API-t.
-
Abu85
HÁZIGAZDA
[link] - Phoronix is megírta.
Azóta egyébként friss infó, hogy a Khronos Group foglalkozik még az OpenGL-lel, de egyelőre nem tudják, hogy merre vigyék tovább. Ezért hibernálták a fejlesztést, amíg tisztul a kép. Elsődlegesen arra kíváncsiak, hogy a Vulkan mellett van-e egyáltalán értelme.
A hírbe is beleírtam, hogy ez miért baj, mert a hibernált a fejlesztés miatt annyira lemarad az API, hogy azok, akik még amúgy maradnának az OpenGL mellett rákényszerülnek a Vulkánra. Tehát önmagában ez a hibernálás végzi ki az API-t.(#24) Jack@l: Ki jelentette ki? Nem ismered a kérdőjelet?
-
-
Abu85
HÁZIGAZDA
Vagy egy ANGLE-höz hasonló felület. Natívot annyira nem éri meg fejleszteni. Az lenne az ideális, ha minden rendszeren lenne natív OpenGL ES támogatás, de mivel ilyen nincs, így kellenek a köztes felületek.
Az Apple speciel natív támogatást használ iOS-re. De ők inkább kivételek.
Új hozzászólás Aktív témák
Hirdetés
- Villanyszerelés
- Magga: PLEX: multimédia az egész lakásban
- 3D nyomtatás
- Miskolc és környéke adok-veszek-beszélgetek
- Autós topik
- Linux kezdőknek
- Melyik tápegységet vegyem?
- NTFS, exFAT, FAT32 – Melyiket válaszd és miért?
- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- EA Sports WRC '23
- További aktív témák...
- ÁRGARANCIA!Épített KomPhone Ryzen 5 5600X 16/32/64GB RAM RX 7600XT 16GB GAMER PC termékbeszámítással
- Xiaomi Redmi A1 32 GB Kártyafüggetlen 1Év Garanciával
- 118 - Lenovo Legion Pro 5 (16ARX8) - AMD Ryzen 9 7945HX, RTX 4070 (ELKELT)
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7800X3D 32/64GB RAM RTX 5070Ti 16GB GAMER PC termékbeszámítással
- BESZÁMÍTÁS! MSI MAG321QR 32 165Hz WQHD 1ms monitor garanciával hibátlan működéssel - használt
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest