- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Prohardver app (nem hivatalos)
- Samsung Galaxy A54 - türelemjáték
- Yettel topik
- Motorola Edge 60 és Edge 60 Pro - és a vas?
- Xiaomi 15 - kicsi telefon nagy energiával
- iPhone topik
- 200 megapixeles zoomkamerát sem kap az S26 Ultra?
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Redmi Note 13 Pro 5G - nem százas, kétszázas!
Új hozzászólás Aktív témák
-
DraXoN
addikt
Nekem semmi, hisz az 5 éves laptopomon is játszható, csak a voxeles megvalósítás "hátrányait" emeltem ki. Gondolom annak is azzal volt baja akinek válaszoltam.
Csak arra gondoltam, hogy a GPU leszármazott APU rész lehet jobban bírja majd a voxeles számítást a jelenlegi CPU-s megoldásnál. De lehet tévedek (csak mivel igen nagyszámú párhuzamos művelet történik ezért gondolom előnyösebb lehet neki).
-
Balala2007
tag
Bocs az offert, de ha mar elokerult:
Publikus a Knights Corner ISA.
Sajna nekem meg nem volt idom attanulmanyozni. -
DraXoN
addikt
válasz
Blindmouse #20 üzenetére
A minecraftnak technológiai oka van a sebességre (nem feltétlen a java, noha igaz egy platform közelebbi nyelvel egy kicsit gyorsabb lenne, de nem lenne akkor se olyan látvány/teljesítmény aránya mint egy modern "rosszul" optimalizált játéknak), noha úgy hiszem, hogy a GPU valóban lehet jobban megfog felelni a feladatnak a rendelerés szempontjából mint a CPU.
-
ddekany
veterán
válasz
Blindmouse #20 üzenetére
Csak ha átdolgozzák a Minecraft készítői, mert szinte kizárt, hogy automatizáltan ki fogja nyerni ez az OpenCL-be átültethető részeket...
-
ddekany
veterán
"Elképzelhető, hogy nem is teszi publikussá az Intel, hiszen más nem fog gyártani erre épülő megoldásokat."
Ha nem teszi publikussá, akkor tényleg nem... Bukásnak hangzik egy HSA-val szemben, aminél bárki fejleszthet új magas szintű megoldásokat (mint amilyen az OpenCL), csak HSAIL-t lökjön ki magából. Na persze, ha látják, hogy már nem megy a kerékkötés tovább, akkor gondolom az Intel is megvalósíthatja a HSA-t.
-
Blindmouse
senior tag
Ez azt jelenti, hogy a minecraft végre normális sebességgel fog futni?
-
P.H.
senior tag
Elképzelhető, hogy nem is teszi publikussá az Intel, hiszen más nem fog gyártani erre épülő megoldásokat. Persze ha a Larrabee New Instructions megegyezik a majdani 512 bites AVX-szel, akkor publikus lehet, de azt nem lehet tudni - egyelőre -, hogy az egyszerűsített utasításkészlet gépi kódolása megváltozott-e (a kihagyott MMX- és SSE-utasítások minimum 3-4 byte-osak, a CPU-s AVX-ek viszont 5-6 byte-nál kezdődnek; ezt az űrt hülyeség lenne kitöltetlenül hagyni).
Ha nem gond, összeszedtem, amit a Xeon Phi-ról tudni lehet most, miben különbözik az x86-tól az új utasításokon kívül, és mi sejhető a jövőt tekintve.
Az x86 valóban szigorú memória-sorrendiségi megkötést ír elő alapesetben, de Pentium 3 óta (SSE1) része az utasításszinten elérhető non-temporal store (nem-átmeneti tárolási) rendszer, amelynek révén a kiírt adat közvetlenül a memóriába kerül, nem jelenik meg a cache-ekben; így nem is kell értesíteni a többi magot sem a változásról, nem generál koherenciaforgalmat. Mára már minden adattípusra van ilyen utasítás: integer regiszterekre, 64, 128 és 256 bites vektorokra egyaránt, megvalósítva a weak memory ordering szemantikát (ami GPU-k vagy ARM CPU-k esetén a default).
Pl. MOVNTPS
A memóriavezérlők 64 byte-os adatszeletek mozgatására vannak kihegyezve (cache-line méret 64 byte), viszont ilyen adattípust nem ismer - jelenleg - az x86. Ezért 64 byte-os puffereket alkalmaznak ezekre az esetekre (2-8 db microarch-tól függően), amelyek a 4-32 byte-os kiírt mozaikelemekből összeállítják (összekombinálják = Write Combining) a 64 byte-ot és ezt küldik el a memóriavezérlőnek. Az eredeti memóriatartalomra csak akkor van szükség, ha az utasítások nem írják felül a mind a 64 byte-ot, ezt nyomon követik a pufferek és a nem módosított byte-ok helyére beolvassák az eredeti értéket, így kerül az a 64 byte a memóriavezérlőhöz.
Hogy mire is jó ez:
- ha ki kell nullázni egy több MB méretű adatterületet, akkor felesleges minden egyes írási műveletnél értesíteni a teljes rendszert, hogy módosítás történt; felesleges beolvasni is az eredeti memóriaértéket, úgyis felülírásra kerül; sőt felesleges a nullákat a cache-be írni, úgysem fér bele az összes.
- memóriamásolásnál szintén szükségtelen a célterület eredeti tartalmát ismernie a CPU-nak, szükségtelen megjelennie a cache-ekben mind a régi, mind az új adatnak
- ez az elv kiterjeszthető az egyes elemekkel végzett számításokra is
Azt, hogy félig feltöltött célterületet másik mag ne kezeljen, ne olvasson bele, úgyis más módon - atomian kezelt jelzőkkel - célszerű megoldani."All other memory types for stores that go through the write buffer (UC, WP, WT and WB) cannot be combined except when the WB memory type is over-ridden for streaming store instructions such as the MOVNTQ and MOVNTI instructions, etc. These instructions use the write buffers and will be write-combined in the same way as address spaces mapped by the MTTR registers and PAT extensions. When WCB is used for streaming store instructions, the buffers are subject to the same flushing events as write-combined address spaces."
Processor_TechDocs/47414_15h_sw_opt_guide.pdf]Appendix AMás a helyzet, ha maguk a vektorregiszterek is 64 byte-osak, azaz 512 bitesek, mint a Xeon Phi esetében: ekkor a non-temporal kiírásuknál nincs szükség sem pufferekre, sem kombinálásra, a tartalmuk közvetlenül mehet a memóriavezérlőhöz. Csak akkor lenne szükség mozaikok összeállítására, ha a kiírt méret kisebb, mint 64 byte: a 64 bites MMX-, a 128 bites SSE- és a 256 bites AVX-vektorok esetén. Pontosan ezeket nem támogatja a Xeon Phi.
64 byte-os vektorok esetén megváltozik a memóriaolvasás is, mivel ott alapesetben a kombinálás fordítottja történik: ha szükség van 1-32 byte-ra, akkor a CPU beolvassa a befoglaló 64 byte-os szeletet az L1D-be, majd onnan a regiszterbe a szükséges adatrészt. Ilyenkor ugyanúgy értesíteni kell a teljes rendszert, hogy ennek a magnak van egy másolata, hogyha valaki nem non-temporal módon módosítja, akkor tudjon róla. Ha viszont 64 byte-os egy regiszter, akkor be lehet vezetni weakly-ordered beolvasást jelentő utasítást is a meglevő mellé, így a beolvasott adat csak a regiszterbe kerül, a cache-be nem . Jól jön ez már akár memóriamásoláskor is, nem írja felül a forrásadat sem a cache-ek értékes tartalmát, főleg pedig olyan számításoknál, amikor egy-egy adatra csak egyszer van szükség.
Ezáltal adott egy, az x86-szemantikához képest csekély koherenciaforgalmat nem generáló weakly-ordered memory model az 512 bites vektorokra.
With a single instruction loading or storing more data, the processor has a better picture about the memory use of the application and does not have to try to piece together the information from the behavior of individual instructions. Furthermore, it becomes more useful to provide load or store instructions which do not affect the caches. With 16 byte wide loads of an SSE register in an x86 CPU, it is a bad idea to use uncached loads since later accesses to the same cache line have to load the data from memory again (in case of cache misses). If, on the other hand, the vector registers are wide enough to hold one or more cache lines, uncached loads or stores do not have negative impacts. It becomes more practical to perform operations on data sets which do not fit into the caches.
8.4 Vector OperationsA HSA dokumentációban olvasható, hogy ők is abban gondolkodnak, hogy a CPU-magok hajtják végre az OS-hívásokat, ez volt az eredeti Larrabee-koncepció is. Viszont nem igazán nevezhető "Latency-Optimized"-nek az a CPU-mag, amely a PCI Express busz túloldalán ül. Ezért az Intel a legegyszerűbb, egyben legpazarlóbb megoldást választotta: meghagyta a teljes x86-magokat az 512-bites végrehajtók körül, azaz épített egy 50-60 magos rendszert, amely önálló OS-t futtat. Ilyen már rég nem nagy feladat csinálni, 12 magon Opteronokból ez 4 foglalatot jelent; csak itt egy lapkára került a teljes rendszer. Ha felrajzoljuk az Opteron-rendszer ábráját, ugyanazt kapjuk, mint a Xeon Phi-nál:
- minden mag saját cache-sel rendelkezik
- a magok csoportokat alkotnak (Opteronnál egy-egy lapka), amelyeknek dedikált többcsatornás memóriavezérlőjük van
- a csoportok rendelkeznek cache directory-val, Opteronnál HT-Assist néven ismert, az L3-ból vesz le 1-2 MB-ot
- a csoportok nagy sebességű busszal vannak összekötve (~HT)Ha ezt a rendszert beköltöztetik a CPU mellé, akkor lehántható a felesleges teljes értékű x86-CPU mag az 512-bites végrehajtókról, hiszen az OS ott fut a szomszédban a post-Haswell magokon, elérni őket nem idő. Marad tehát egy maréknyi 512-bites vektorvégrehajtó saját utasításkészlettel, fejenként körítve utasításkezeléssel, skalár integer/FP egységgel és némi cache-sel. Mivel a vektorműveletek többnyire megkerülik a cache-t, ezért azok csak néhány kisebb feladata lesznek jók:
- konstansok, táblázatok tárolására, melyeknek nincs hely regiszterben (read only cache)
- skalár feladatok tárhelyének, ideiglenes adatok változóinak (read-write L1)
- atomi, szinkronizációs és megosztási feladatok ellátására (data share)
Ez így pedig már eléggé emlékeztet valamire... -
-
-
Az oracle koncentrálhatna az aktuális biztonsági rések befoltozására is, még mindig nyitva van a szept elején publikált rés...
-
Cathulhu
addikt
Mi ertelme egy ilyen szovetsegnek amugy? Androidnal hasznos lehetne, de ott meg pont nem OracleWM dolgozik, mas java-s dolgot meg nem nagyon tudok elkepzelni, amin sokat dobna a GPU gyorsitas.
-
Abu85
HÁZIGAZDA
Finalizer nélkül a HSA alkalmazás csak az AMD64(x86-64)-es központi processzormagokon fut, vagyis a Larrabee magok nem számítanak. Utóbbi a közhiedelemmel ellentétben nem lesz binárisan kompatibilis a fő magokkal. A sok pici mag tehát funkcionálisan nem lesz jobb integráltsági szinten bekötve, mint mondjuk a GCN az AMD APU-kba. Ergo azok működtetéséhez kelleni fog az Intelnek a HSA finalizer, amit ha nem írnak meg, akkor lényegében nem fog futni a kód a lapka GPU részén.
-
DraXoN
addikt
Ez nem szerencsés döntés az Intel részéről, ha a HSA valóban befut.
Idővel szerintem nekik is be kell majd lépni, mert különben az ő rendszerükre nehezebb lehet programozni oly módon, hogy a teljes rendelkezésre álló teljesítményt kihasználhassuk.Bár érthető, hogy nem ugranak bele a szabványba azonnal, nincs még kész platformjuk rendes fordítókkal.. vagy 2-3 év lemaradásban vannak legalább az AMD-hez képest, így húzzák ameddig csak tudják (mint az OpenCL drivert a Sandy-hoz..).
Lehetséges még, hogy valami alternatív szabványt próbálnak majd adni a fejlesztőknek HSA-helyett, de figyelembe véve a HSA támogatottságát, a sikerére nem sok esélyt látok (főleg, hogy ha meg is lépi, valószínű nagyon későn jönne.. a HSA is eléggé régóta van tervezés alatt és csak most látszik az 1.0ás specifikáció a célegyenesben.. ha jól tudom)
-
T_Stark
őstag
Az AMD-nek lassan mindenben benne lesz a keze
Az a jó, csinálják csak.#2 FireKeeper
+1 -
Abu85
HÁZIGAZDA
Érdemes, mert az Intel sosem fog belépni a HSA alapítványba. Az x86 egy ilyen lépéssel elvesztené az értékét. Tehát ez valószínűleg úgy lesz megoldva, hogy amelyik hardver HSA-képes, annak kapásból mehet a HSAIL-re a kód. Az OpenCL opciót viszont érdemes megtartani a többieknek.
-
ddekany
veterán
Ne tegyél egyenlőségjelet a Java és az Appletek közé... Főleg mert ellenben a Flash-al, a Java azon a téren már rég feladta a küzdelmet, csak nagy ritkán még vannak oldalak amik használják. A Java elsősorban szerver oldalon lett sikeres és rohadt elterjedt nagyobb cégeknél, csak ebből a laikusok nem látnak semmit. Lehet, hogy az Oracle is elsősorban a szervertermekbe szánja ezt az OpenCL integrációt. (Meg valamennyire desktop alkalmazásoknál is az lett, bár abban nincs mindig köszönet...)
-
banhammer
veterán
"a Java 8 várható bemutatkozásáig már kevés az idő, így vagy kiegészítésként, vagy a Java 9-ben érkezik az új rendszer."
A Java 8-at is már vagy másfél éve készítik és jelenleg a 8.0 Build 58 Preview-nál tartanak.
Szóval nem kell félni, hogy hipp-hopp elkészül. -
ddekany
veterán
Vajon ha a HSA kiforr megvalósításában, még mindig érdemes lesz az OpenCL-es lépcsőnek, vagy a JVM kapásból HSAIL-t generál majd?
-
Raysen623
addikt
Én inkáb arra törekednék hogy a Java-t és a flash-t örökre eltüntessem az internet világából! Kártékony állatok....
-
FireKeeper
nagyúr
ez szep es jo, de inkabb a trinity teszt johetne
-
GIJoe
addikt
Végre lesz egy relatíve normális társa az Oracle-nek...
Új hozzászólás Aktív témák
Hirdetés
- Óra topik
- Linux kezdőknek
- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- Sorozatok
- Kezdő fotósok digitális fényképei
- Windows 11
- Sugárhajtómű ihlette a Zalman CPU-hűtőjét, de nem az üzemzaj tekintetében
- Dune: Awakening
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Diablo IV
- További aktív témák...
- ÁRGARANCIA!Épített KomPhone Ryzen 9 5900X 16/32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- 30+ típus!!! Lenovo Thinkpad X1 Carbon, Thinkbook, 2-in-1 Workstation, Yoga, 5-14.gen. Ultra 7!!!
- Csere-Beszámítás! AMD Számítógép PC Játékra! R5 5500 / RX 5700XT / 32GB DDR4 / 256SSD+1TB HDD
- Csere-Beszámítás! Olcsó Számítógép PC Játékra! R5 1500X / RX 570 8GB / 16GB DDR4 / 250SSD + 2TB HDD
- AZONNALI SZÁLLÍTÁSSAL Eladó Windows 8 / 8.1 Pro
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest