Új hozzászólás Aktív témák
-
hallador
addikt
Én eddig csak egy helyen láttam az AVX1/2 előnyét de ott mocskosul nagyon, a videóvágás, amíg egy sima dual xeon szervert (Amibe nincs AVX) agyonver egy Ivy i5, nem beszélve a Haswell i5-ről, egy sima real time videó konvertben, akkor látom miért jó az AVX nekem. Másban én sem érzem.
Természetesen, rétegfelhasználásról van szó, nem sok ember tart fenn nagy teljesítményű gépeket ilyen célokra. Nem Pentium/Atom/AMD APU kategóriás móka.
-
#20
ƬΛЯΛ
senior tag
Meteorhead
#1
ƬΛЯΛ
senior tag
válasz
Meteorhead
#1
üzenetére
Én is annak tartom, nem vagy egyedül
-
#19
LordX
veterán
Meteorhead
#18
LordX
veterán
válasz
Meteorhead
#18
üzenetére
Pont alátámasztod amit én írtam: még nem láttam olyan OpenCL kódot, ami gyorsabb lenne AVX-en, mint iGPU-n
Natív AVX-es x86 kód esetleg, de a cikk problémafelvetése az, hogy nem éri meg fejleszteni rá.Egyébként hülye is lennék contextet csak ezért beizzítani..
Az egyszer készül el inicializálásakor, és onnan használom folyamatosan. Ilyen alapon a kód újrafordítását is bele lehetne venni az időbe. Ami idő, az csak az argumentumok beállítása és a kernel launch - Intelen ez relatíve olcsó; diszkrét AMD/nV kártyán drágább.Azt is vedd figyelembe, hogy ha ügyes vagy, közben a proci csinálhat mást is. (Bár az Intel hülye turbó implementációja miatt nem sok mindent.)
-
#18
Meteorhead
aktív tag
LordX
#16
Meteorhead
aktív tag
Pedig van, csak a válasz mint mindig: attól függ.
Egy 100, vagy 400 elemű vektor feldolgozását nem akarod az IGP-vel csináltatni, mert túl sok meló beizzítani a contextet, nomeg a memória késleltetés is nagyobb. A CPU már rég végzett volna a feladattal. Ott viszont AVX-szel negyedelni lehet a feldolgozási időt. Ez csak egy példa, de vannak más esetek is, amikor azért nem rossz, ha van AVX, és minél okosabb, annál jobb.
Az a vonal, amit a Skylake fog követni, hogy a lapka 70%-a IGP az tetszik. Legyen 2, nagyon max 4 mag HT-vel, és a többi legyen IGP meg fixed function. AMD-nek a bulldozer elképzelése sem volt rossz, 1 modul 2 integer egységgel, és osztozzanak a lebeőpontos ALU-n. A CPU-nak egyre inkább karmester szerepe lesz, csak drivert fog bözgetni, memóriacímeket számol, és egyre kisebb lesz játékok alatt az FPU terhelése. Ha az egész játékmotort kirakják IGP-re (ami felé haladunk), egy darab lebegőpontos műveletet nem fog elvégezni. A program counter léptetéséhez integer egység kell, méghozzá gyors. Szóval az AMD-s "Hyper Threading" elv tetszett, csak bedrótozni nem tudták. Kaveri már itt is hozott sokat, külön decode mindkét integernek, stb. de mire felhozzák jó szintre, addigra architektúrát fognak váltani.
-
lenox
veterán
Az intel eleg jol szivatja magat szerintem ezzel az avx-szel, nem tudom, pontosan miert jo ez... Meg a haswell pentiumok se tudjak a mezei avx-et se, igy ki lenne az, aki erre fejleszt? Csak olyan, aki nem tomegeknek fejleszt, ellenben keves rendszerert sok penzt fizetnek, ez nyilvan nem a jatekfejlesztes.
De mondjuk egy dolog eszembe jut, mac-eknel megerheti... Persze ott sem a jatek, de van egy par szoftver, amit az apple arul.
#16: dual haswell xeonokon azert lehet, hogy jo lesz...
-
#16
LordX
veterán
Meteorhead
#1
LordX
veterán
válasz
Meteorhead
#1
üzenetére
Még nem láttam olyan OpenCL kódot, ami gyorsabb lett volna AVX2-n, mint a lehető leggyengébb Intel HD Graphics-on. Az meg nagyon macera, hogy több sort fenntartasz és kézzel ütemezgeted ide vagy oda a feladatokat, arról nem is beszélve, hogy amiben AVX2 is van (Haswell), abban a GPGPU is gyorsabb.
Ennek ellenére az Intel konklúziója hülyeség: azért nem érdekli senkit az AVX2/3.2, mert a Celeronokban, Pentiumokban és AMD-kben nincs, és ez által kilőtted a piac olyan 80%-át... Az AVX1 is csak azért kell, mert a konzolban levő AMD tudja, de a Celeron-Pentium nem.
-
Abu85
HÁZIGAZDA
Ez nincs így. Az ARM is elmondta, hogy az AMD-nek csak azért van két vezetőségi tagja, mert Phil Rogerst szavazták meg a HSA élére egyfajta technikai vezetőnek. De ettől még nem adtak az AMD-nek extra szavazati jogot, tehát ugyanúgy egyet ér az AMD szavazata, mint a többieké. A két AMD-s BoD tag közül csak az egyik szavazhat, míg Phil Rogers gyakorlatilag egyfajta "házelnöki" szerepkört tölt be.
-
#13
pakriksz
őstag
Meteorhead
#9
pakriksz
őstag
válasz
Meteorhead
#9
üzenetére
azért nem akar belépni mert:
-az amd a főkolompos a HSA-ban
- nem az intel találta ki és irányítja az egészet a neki megfelelő irányba -
#12
Abu85
HÁZIGAZDA
Meteorhead
#9
Abu85
HÁZIGAZDA
válasz
Meteorhead
#9
üzenetére
Nem igazán. Inkább úgy mondanám, hogy ha a HSA runtime nem talál kompatibilis gyorsítókat, akkor ugyanazt a programot valamelyik SIMD ISA-ra fordítja. Ha AVX2 elérhető, akkor arra. SSE2 lesz a minimum, amit megkövetel.
A HSA konzorcium azon dolgozik, hogy egy forrásból kiszolgáld az összes létező architektúrát/gyorsítót/stb. Ez azt jelenti, hogy vége a duopóliumnak, mert ugyanazokat a programokat futtatnák az ARM-os gyártók is. Egyértelmű, hogy ez a piaci részesedés drasztikus csökkenéséhez vezetne, már csak azért is, mert legalább 10 gyártó pályázna még ugyanarra a szeletre.
-
#11
Balala2007
tag
freeapro
#3
Balala2007
tag
AVX:
- 3 v. 4 operandusos non-destruktiv utasitasformatum, float es double tipusokra
- 128->256 bit szeles regiszterek
- alignment megszoritasok feloldasa
AVX2:
- integer support
- gather
- FMA
AVX512F (tobbszaz uj utasitas):
- maszk regiszterek
- 256->512 bites regiszterek
- 16->32 SIMD regiszter
- implicit broadcast
- roviditett memoriacimzes
- scatter
AVX512CD (3 db uj utasitas)
AVX512ER (10 db uj utasitas)
AVX512PF (4 db uj utasitas) -
#10
Kotomicuki
senior tag
Meteorhead
#9
Kotomicuki
senior tag
válasz
Meteorhead
#9
üzenetére
A zintel nem belépni szeretne vhová, hanem ő akarná kijelölni a többiek által is bejárandó utat, hogy továbbra is ő maradhasson a csúcson - egyedül - , csakhogy a monopóliuma kezd halványulni, mert a nem fejlesztésnek - vagy a többiekkel szembe való fejlesztésnek - , meg a kitúrósdi "piaci" viselkedésnek ez lesz a következménye.
Egye meg amit kotyvasztott - ezt is a részvényes, ha már évekig abból éltek, hogy sárba döngölik a PC-t!Ha hagyta volna a többi szereplőt is (pl. Cyrix, Via, nV), legalább a morzsákon vegetálni - netán, még össze is dolgozni velük... - , akkor nem kéne azon keseregnie, hogy a háztartásokban "csak" multimédiás- és játékgépként tartott PC-t mára már minden elmebeteg "ötlet" ki tudja szorítani a piacon ezen szerepkörből - a játékkonzolokról nem is beszélve.
-
#9
Meteorhead
aktív tag
Abu85
#2
-
Nekem kicsit fúra az egész cikk, Javítsatok ki ha rosszul értem....
Andrew Lauritzen szerint bár az AVX rendületlenül fejlődik, azzal kapcsolatban rendkívül szkeptikus, hogy ennek valaha is látjuk majd az előnyét a PC-s játékokban. Az Intel grafikus részlegének szoftverfejlesztője azt is hozzátette, hogy az új generációs konzolok felépítése sincs jó hatással az új AVX utasításkészletek potenciális terjedésére vonatkozóan.
Egy Inteles fejes picsog, hogy miért nem használja senki, mikor én nagyon szeretném...
Konzolban nincs. Intel eladott procijainak kb 20%ban van.
Ugyan I5-I7 szóval a két legdrágább procba benne van....AVX2 és az AVX 3.2 esetében egyszerűen semmilyen kutatás nem zajlik.
Most én kérdem hülye ez ???
Nem értem mit nyavalyog, hogy fogja mindenki elhagyni a jól bevált támogatott utat és áttérni AVX-ra, mert ő egy személyben azt mondja az a tuti ???
Hiszen ti is leírjátok neki : csak PC-n elérhető technológiák megismerésére nem fognak külön pénzt és időt áldozni.
Vagy mire fel akarja, hogy mégis megtegyék ezt ? -
#7
bitblueduck
senior tag
bitblueduck
senior tag
Mondjuk egy tipikus konzolport PC-re fordításánál egy -xavx paraméter is több effort lenne, mint amit összesen csinálnak és az nem kerül sokba.
-
Diocles
aktív tag
"viszont a hat évvel korábban bemutatott AVX-hez" - ez azt sugallja, mintha az AVX-et hat évvel korábban mutatták volna be az SSE-nél. A "hat éve bemutatott AVX" egyértelmű lenne.
A másik, hogy a támogatottság hiányában az Intel a legnagyobb hunyó. Pont a Celeronok és Pentiumok nem támogatják az AVX-et, amelyeknek a legnagyobb szüksége lenne rá. Egy i7 már izomból is megoldja a feladatot. Minek szívjanak a fejlesztők az AVX optimalizációval, ha a gyengébb procik úgysem profitálnak belőle.
Eközben AMD fronton a legalsó kategóriában is van AVX.
-
Abu85
HÁZIGAZDA
Csak használhatják, de senki sem mondta, hogy használni is fogják. Természetesen maga a technika használható natívan, OpenCL-ben, HSA runtime mellett, és máshogy (kevésbé célszerű módokon), de mindegyikhez kell egy alapvető kutatás, hogy hatékony legyen a kód. A pénzt viszont a GPGPU kapja és nem az AVX2+. Nyilván az Intel fejlesztője látja, hogy zéró pénz megy az AVX2+ megismerésére, vagyis még ha járulékosan van is lehetőség hatékonyan használni (például OpenCL), akkor is a GPGPU a fókuszt, vagyis a kód is arra lesz optimalizálva. Ez már okot ad a szkepticizmusra.
(#6) Diocles: Átírva köszi.
-
#2
Abu85
HÁZIGAZDA
Meteorhead
#1
Abu85
HÁZIGAZDA
válasz
Meteorhead
#1
üzenetére
Az Intel az OpenCL-en és a HSA-n keresztüli megoldást nem tartja támogatásnak, csak járulékos nyereségnek. Támogatásnak a natív implementációt tekintik. Utóbbira az AVX2+ esetében kicsi az esély, főleg úgy, hogy nincsenek ilyen irányú kutatások.
Természetes az AVX2 például kihasználható lesz a HSA runtime-on keresztül. Talán ez az egyik fő ok, hogy érdektelen a fejlesztők szemében a natív támogatás. Írnak egy kódot és fut az is, majdnem olyan hatékonyan, mintha natívan fordítanák le. -
#1
Meteorhead
aktív tag
Meteorhead
aktív tag
Ezt csak én tartom egy nagy szamárságnak?
Intel reklámozza olyan fene nagyon, hogy OpenCL-ben írjanak játékokat. (Mondjuk ezt nem is értem hogyan lehetne egy egész motort felhúzni C-s compute API-ra, de biztos meg lehet oldani.) Ott maximálisan megoldott, hogy ki legyen használva az AVX akármelyik verziója, hiszen a fordító skalár kódot is ráhúz az AVX sávokra, felismeri a gather/scatter műveleteket és be tudja illeszteni az adott hardverhez illeszkedő leggyorsabb műveleteket AVX verziótól függően.
Ugyanezt meg tudná csinálni C++AMP-ban, hiszen minden valamirevaló compiler ismeri az AVX összes verzióját és felismeri azokat a triviális műveleteket amiket használni lehet. Nem hiszem el, hogy csak explicit ASM utasításokkal lehetne értelmesen használni AVX-et.
Akkor meg hol a gond? Minden valamirevaló nyelv/API lehetőséget ad a kihasználására.
Natív AVX-es x86 kód esetleg, de a cikk problémafelvetése az, hogy nem éri meg fejleszteni rá.
Az egyszer készül el inicializálásakor, és onnan használom folyamatosan. Ilyen alapon a kód újrafordítását is bele lehetne venni az időbe. Ami idő, az csak az argumentumok beállítása és a kernel launch - Intelen ez relatíve olcsó; diszkrét AMD/nV kártyán drágább.
Új hozzászólás Aktív témák
- Samsung Galaxy Z Fold7 - ezt vártuk, de…
- Kuponkunyeráló
- ASUS routerek
- Hatalmas kedvezménnyel nyit az Ulefone új csúcsmodellje
- Lakáshitel, lakásvásárlás
- PlayStation 5
- S.T.A.L.K.E.R.: Shadow of Chernobyl
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- Apple asztali gépek
- Google Chrome
- További aktív témák...
- Telefon felvásárlás!! Samsung Galaxy S25, Samsung Galaxy S25 Plus, Samsung Galaxy S25 Ultra
- Lenovo IdeaPad S10-2 netbook jó akkumulátorral eladó
- Xiaomi Redmi Note 13 Pro 5G 256GB, Kártyafüggetlen, 1 Év Garanciával
- Fujitsu LIFEBOOK E449 i5-8130U 12GB 512GB 14" FHD 1 év garancia
- Felújított számítógépek számlával, garanciával! Ingyen Foxpost!
Állásajánlatok
Cég: FOTC
Város: Budapest