Na, ez igazán abuista verzió lett!
8 óra munka, 8 óra pihenés, 8 óra kijárási korlátozás
Na, ez igazán abuista verzió lett!
8 óra munka, 8 óra pihenés, 8 óra kijárási korlátozás
RX 570 videókártyával működni fog?
https://sites.google.com/view/saviorweboldala/home
[ Szerkesztve ]
"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) PSN: Wijberto: Xbox Live : Tiboa
Miért nem nevezik már Dx13-nak például, ha ennyi változás jön, simán lehetne verziószámot ugrani. Sokkal egyértelműbb lenne a kompatibilitási lista is, melyik VGA család támogatja még, melyik már nem, stb.
[ Szerkesztve ]
A tehén egy bonyolult állat, de ÉN megfejtem...| 2016-tól az tuti, hogy az angyalok is esznek babot...
Te se értesz belőle egy szót se?
@tibaimp:
Mint amikor próbálod követni az USB szabványokat.
TL;DR... jobb lesz.
#4 tibaimp : Hát ha minden képességet nem is, de az erőforrások dinamikus bekötését a GCN2+, az RDNA összes, a Turing összes, az Ampere összes, illetve a gen9+ biztosan támogatja. De szerintem, amire van TIER_3-as binding, arra rá lehet emulálni.
[ Szerkesztve ]
De, értem. Az abuizmus számomra abban merül ki, hogy minden is mindenféleképp is programozható, szóval újabb limitek szűnnek meg és millió lehetőség, hatékonyabb megoldás lesz elérhető stb.
8 óra munka, 8 óra pihenés, 8 óra kijárási korlátozás
Amiből az következik, hogy az engine fejlesztők örülnek hogy mindent is kontrollálhatnak és szarrá optimalizálhatják az enginet.
Addig amíg nem kell vele a régihez "majd a driver meg az API megoldja ha szarul is" képest 5x annyit dolgozni. Ja azt már kösz nem kérjük
A Linux rendkívül felhasználóbarát, csak megválogatja a barátait
Ja, az engine fejlesztőknek ez nagyon extra lehetőség technológiai maszturbációra.
[ Szerkesztve ]
8 óra munka, 8 óra pihenés, 8 óra kijárási korlátozás
Képzelem ahogy a meetingen előadja, hogy hát főnök ezzel az új feature-el ha még ülnék egy fél évet a kódon akkor sokkal gyorsabb lenne az engine.
Magam előtt látom a manager idegtől eltorzuló arcát
[ Szerkesztve ]
A Linux rendkívül felhasználóbarát, csak megválogatja a barátait
Itt lehet jelezni a fordítási hibákat? (Itt az eredeti)
Szóval új atomi (szintű nélkül) műveletek jönnek, egyrészt 64 bites integerekre, másrészt floatokra (magyarul: lebegőpontos érték, nem pedig lebegőpontos értékeket tároló erőforrás) olyanok, amik szimpla bitszintű összehasonlítást használnak, nem pedig rendes floating point összehasonlítást (vagyis gyakorlatilag simán intre castolják a floatot).
A packed math meg igazán most jelenik meg, eddig összesen egy darab művelet volt (dot product), az is egyébként 8 bites integerekre (signed meg unsigned változatban).
A wave-nél nem azt lehet megadni, hogy milyen méretűre forduljon le, hanem azt lehet megadni, hogy az adott compute shade mekkora wave mérettel kompatibilis és ennek eredményeképpen a driver vagy pont ekkora wave-et fog futtatni vagy hibát dob.
A Microsoft nem azt javasolja, hogy csak egy paraméter legyen meghatározva (ez így egyébként is teljesen értelmetlen mondat), hanem azt, hogy csak akkor adjon meg az ember ilyen korlátozást, ha tényleg csak egyetlen egy wave size jó a shadernek.
DRM is theft
Köszi az infót!
siposz: ja, az meg a másik
A tehén egy bonyolult állat, de ÉN megfejtem...| 2016-tól az tuti, hogy az angyalok is esznek babot...
A szintűt kivettem, ha ennyire zavar.
A lebegőpontos értékeket erőforrásokban tárolják.
Senki sem írta, hogy a packed math új.
Pont az a lényege, hogy ezt megadd, mert amúgy a meghajtó fordítójának szabad keze van benne.
Vagyis egy paraméter legyen meghatározva, hiszen egyetlen egy wave-méret jó a shadernek. Ha több is jó, akkor felesleges attribútumról van szó, hiszen a fordító jobban tudja, hogy mi a jó a hardvernek.
A szintűt kivettem, ha ennyire zavar.
Szerintem ha rosszul fordítasz valamit, az elsősorban téged kellene, hogy zavarjon.
A lebegőpontos értékeket erőforrásokban tárolják.
A fenéket.
Senki sem írta, hogy a packed math új.
De, én.
Amit te írtál, abból ugyanis az következik, hogy eddig is volt, csak éppen nem 8 bites intekre, ami viszont nem igaz.
Pont az a lényege, hogy ezt megadd, mert amúgy a meghajtó fordítójának szabad keze van benne.
Ez nem a fordítóról szól.
Vagyis egy paraméter legyen meghatározva
Érted te azt, amit beszélsz? Egyáltalán, tudod, hogy mi az a wave?
DRM is theft
Hát mik tárolják? Pufferben vagy textúrában vannak. Mindkettő erőforrás.
Packed math eddig FP16-ra volt. Int8 natív vagy mixed módban volt, de nem packedben.
Hát miről? Béláról?
Te tudod? Én azért jó négy oldalt írtam erről korábban. [link] - ettől az oldaltól kezdve.
Maga a meghatározás azért fontos, mert a modernebb hardverek, mint az RDNA, már nem csak egy wave-méretet támogatnak hatékonyan, hanem kettőt is. Arról a shader fordító dönt, hogy egy shadert hogyan fordít le. Viszont a shader model 6.6-től kezdve a fejlesztő megmondhatja, hogy a shader fordító 32 vagy 64 lane-es wave-et használjon az RDNA-n például. Más hardveren ennek sok értelme nincs, mivel a min és a max wave-méret megegyezik, de nyilván ez egy jövőnek szánt funkció, egyre több hardver lesz olyan, mint az RDNA, így hosszabb távon a multiprocesszorok többféle wave-mérettel is hatékonyan tudnak majd működni.
[ Szerkesztve ]
Ha készítenél egy két ábrát érthetőbb/követhetőbb lenne.
"DOS addresses only 1 Megabyte of RAM because we cannot imagine any applications needing more." Microsoft in 1980 "We can" -said Google, than they made Chrome. What happend next is history.
Hát mik tárolják? Pufferben vagy textúrában vannak. Mindkettő erőforrás.
Jézusom. Regiszterekről még nem hallottál? A buffer meg a texture-t senki sem emlegeti "erőforrás" néven. A resource-ok azok meg tök mások.
Packed math eddig FP16-ra volt.
HLSL-ben nem volt.
DRM is theft
A mai GPU-kban statikus erőforrás-allokáció van, vagyis a regiszterek és az LDS tekintetében a shader fordító egyszerűen betöltet mindent. Ez a program oldaláról csak annyiban kontrollálható, hogy a regiszternyomást mennyire optimalizálják, de ennél direktebben ebbe nem tudnak beleszólni, nem elég okosak hozzá a mai hardverek.
Nem tudtam, hogy a Microsoft az senki. Köszi a felvilágosítást.
"min16float"
Az újabb HLSL verziókban már jól működik.
A régebbi nyelv, a 2019-es HLSL verzió előtt, amit még az FXC-hez terveztek ugyan kellettek trükkök, hogy ne 32 bites legyen az alignmentálás, de elég egyszerűen megoldható volt.
Kellett egy CPU-oldali kód, ami uintbe csomagolta a konstans és pufferadatokat, és ezek kezelhetővé váltak a GPU oldalán két sor kód beírása után. Másképp ugye aligha futott volna például a TressFX a játékokban, hiszen az exkluzívan packed mathot használt FP16-ra.
Ma már ezek nem kellenek, a Microsoft megoldotta ennek a támogatását trükkök nélkül is.
[ Szerkesztve ]