- AMD Navi Radeon™ RX 7xxx sorozat
- AMD GPU-k jövője - amit tudni vélünk
- Apple notebookok
- Soundbar, soundplate, hangprojektor
- Azonnali informatikai kérdések órája
- Hisense LCD és LED TV-k
- eGPU tapasztalatok
- AMD APU (AM4 és AM5) topik
- Amlogic S905, S912 processzoros készülékek
- Milyen asztali (teljes vagy fél-) gépet vegyek?
Új hozzászólás Aktív témák
-
Cassi
őstag
Igen, de a becslések szerint csak a GPU-k kb. 25%-a került a bányászokhoz, tehát a lényegen nem változtat. Csak arra az állításra reagáltam, hogy a Gaming mint piac súlya nem jelentős - de valójában nagyon is.
Most éppen egy crash felé haladó tőzsdei lejtmenet tart, vélhetően sokat veszít a súlyából a crypto és szerintem az AI-alapú rendszerek gyártói közül is sokan ellhullanak majd. Hiába ölnek sokan nagy pénzeket például az önvezető autók hardverébe, a piac egyelőre nincs meg hozzá. A gaming viszont erős maradhat.
-
#46
ddekany
veterán
fatpingvin
#20
ddekany
veterán
válasz
fatpingvin
#20
üzenetére
"nézd meg mennyi tényleg totál felesleges csontváz van benne még a legmodernebb x86 procikban is."
Azt kellene megnézni, hogy az a sok csontváz hány százalékát viszi el CPU területének, és mennyire tesz keresztbe az olyan funkcióknak, mint a függőségek kezelése (utasitás szintű párhuzamosítás és átrendezés), a spekulatív végrehajtás, stb. Mivel nem tervezek CPU-kat, én itt csak arra tudok támaszkodni, amit hozzáértőktől olvastam (mint Jim Keller), és ott az volt a konklúzió, hogy néhány % teljesítmény veszteségről beszélünk ha kb azonos területű/fogyasztású CPU-ról van szó. (Ez teljesítmény orientált CPU-kra vonatkozik, nem beágyazott minimalista magokra, mert utóbbiakban sokkal nagyobb a súlya csontvázaknak, a mindenféle általánosabb IPC nővelő logika mellett.)
[ Szerkesztve ]
-
#45
E.Kaufmann
veterán
fatpingvin
#44
E.Kaufmann
veterán
válasz
fatpingvin
#44
üzenetére
Annak a szoftverét meg nem nyitják (gondolom, néha csak kellene azt is frissíteni), hanem zárt firmware
![;]](//cdn.rios.hu/dl/s/v1.gif)
? Adtak is meg nem is? 
Le az elipszilonos jével, éljen a "j" !!!
-
#44
fatpingvin
addikt
E.Kaufmann
#42
fatpingvin
addikt
válasz
E.Kaufmann
#42
üzenetére
feltételezem igen, ugyanis az újabb kártyákon egy beágyazott RISC-V proesszor csinálja azt a managementet amit a régebbieken a kernel driver tolt nagyrészt szoftverből. ez azért egy elég vastag különbség, ugyanis az újabb esetben csak ezzel a management processzorral kell beszélgetni, nem magával a hardver egyes elemeivel.
A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)
-
#43
dchard
veterán
E.Kaufmann
#42
dchard
veterán
válasz
E.Kaufmann
#42
üzenetére
"Only Turing and newer GPUs will be supported by this open-source kernel driver.... Turing and newer is a hard requirement due to being dependent upon the GPU System Processor (GSP)."
Ezt állítja az Nvidia. És akkor jönnek itt azzal, hogy milyen csodás munkát végez az Nvidia a régebbi driverek életbentartásával az újabb kerneleken... A 390-hez most jött ki javítás, lehet meg kéne próbálnom ezt az új változatot, de rengeteg meló... A kártya maga jól működik (hivatalosan támogatott is a 390-es verzión), csak éppen az OpenCL kakálja össze magát, ha bármi újabbon próbálom, mint a 334... A Nouveau meg nem tud OpenCL-t amennyire látom, úgy általában elég kevés az info Nouveau + Compute ügyben... Pedig örömmel váltanék Nouveau-ra...
[ Szerkesztve ]
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
#42
E.Kaufmann
veterán
dchard
#41
E.Kaufmann
veterán
-
dchard
veterán
Amikor megláttam, hogy gyak három generációt fed le a nyílt forrású meghajtó, miközben a zárt forrású driverek életben tartása az új kerneleken az egyik legnagyobb kihívás a visszamenőleges támogatás megőrzése miatt, hát nem fogott el az öröm, hogy finom legyek
Mire találtam egy kernel-driver párt, amin az opencl rendesen működött, majdnem kihullott a hajam, és ez a 334 + 5.4.x. Elvileg a 390-ben is tökéletesen támogatott a hardverem, de a valóságban mégis szétomlik a fenébe, pedig az összes létező keresztfüggést darabonként átnéztem... Szóval beragadtam egy ezer éves kernelbe a kurva nvidia meg a zárt forrású szara miatt. Azért neked válaszoltam, mert látom hogy átérzed a nyomoromat.A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
Reggie0
félisten
Latom nem erted. A felhasznalok nagyobbik reszenek sosem lesz vele baja, de ettol meg nem jo minosegu. Azt te mi alapjan tudod megallapitani, hogy jo minosegu?
Az. hogy random lefagy tole a gep eleg sulyos hiba, ez nem is kerdes. Egy notebooknal alap, hogy monitort dugsz ra es lehuzod, suspendeled, stb..
Nyilvan fixelgethetnem az amdgpu modult, csak van boven mas dolgom. Ha otthon unatkoznek, akkor reg azt csinalnam.
#39 fatpingvin:
Mint lentebb irtam: random fagyasok hasznalat kozben vagy suspendnel, monitor csatlakoztatasnal, eltavolitasnal, stb.. 2500U-val sikerult egy stabil allapotig eljutni a 4.x-es kernelen, de 5.x-el megint szarakodik ossze vissza.[ Szerkesztve ]
-
#39
fatpingvin
addikt
Reggie0
#29
-
lev258
veterán
Nekem az van, csak nem U-s. És semmi baja már bő egy éve.
Az teljesen normális a kernelfejlesztésben, hogy sok bug bejelentés van. A súlyosságuk a lényeges kérdés.
Az Archwiki meg mindig részletes volt, az ott szereplő kerülő megoldások valószínűleg olyan hibákra vonatkoznak (legalábbis jó részük), amik a kezdeti időkben voltak jelen és már javítva lettek.
Jelenleg az AMD Linuxos driverei messzemenően jó minőségűek, időnként az Intel támogatást is túlszárnyalják. Nem akarlak meggyőzni semmiről, de újból hangsúlyoznám, hogy ha meg akarsz oldani konkrét problémákat, arra van lehetőség, csak tenni kell érte. Ha erre nem vállalkozol, akkor olyan rendszert használj, amivel elégedett leszel.Ubuntu MATE 20.04, hobbi cayenne termesztő
-
Reggie0
félisten
Peldaul ott van benne ez is:
"drm/amdgpu: disable 3DCGCG on picasso/raven1 to avoid compute hang"A firmwareben is vannak bugok jocskan, de a kernelmodulban is. Nezd meg mennyi problema es bugreport jott 2018 ota. Vagy nezd meg mennyi workaround van mondjuk az archwikin a kulonbozo fagyasos problemakra: [link]
Egy 2500U-s thinkpad es egy 3700U-s elitebook utan azt mondom, hogy ha valaki mobil ryzennel akar linuxozni az varjon meg 5 evet.
-
lev258
veterán
Kicsit még olvasgattam, és úgy látom, az ilyen jellegű probléma (3500U-ra találtam) le lett szűkítve az AMD firmware csomagra, abból kell a jó verzió, nem a kernelből. Szóval ez inkább egy véletlenül becsúszott technikai malőrnek tűnik és ezért érint csak egy szűk felhasználói réteget.
Ubuntu MATE 20.04, hobbi cayenne termesztő
-
lev258
veterán
Amit linkeltél, abban pont nem látok olyan gondokat, mint amiket írsz (mellesleg még csak nem is a rendes 5.14-es, hanem a legelső teszt verzió). Ha hibát tapasztalsz, jelents be, akkor gyorsabban megoldódik. Több értelmét látom, mint olyan rendszert használni, amit folyamatosan szidsz. Vagy használj Windows-t, ha ott nem jön elő ilyen.
[ Szerkesztve ]
Ubuntu MATE 20.04, hobbi cayenne termesztő
-
totron
addikt
az első driverek még nem lesznek bugmentesek
Pontosan ez a félelmem, ugyanis a minőségek tükrében könnyen lehet, hogy a népezet egy kalap szarral ajándékozódott meg/ajándékozza meg magát. Mindemellé persze juhéjj, meg minden.(#20) fatpingvin, anno a kortárs x86 designokhoz
Irreleváns. Azóta egyébként is nyílt az olló, alaposan. Tehát ez nem technikai érv. De ha interpolálod egészen a mai kor teljesítményéig, hogyan haladt és gyarapodott volna a POWER-SPARC-Alpha vonal, biztosan nem vitatkozom veled. Jól eső idealizálni az egzotikumot, én ezt látom ebben a véleményben. Amivel nincs gond, amíg a helyén van kezelve és kommunikálva.később ebből bármi lehessen
Ez ennyi és nem tovább. -
Reggie0
félisten
válasz
#94257664
#31
üzenetére
Ha tobbsegben lennek, akkor nagyonszar lenne. Ha egy driverrel a felhasznalok 5%-anak problemaja van, az mar nagy bajnak szamit.
Az meg nem izgat, hogy foglalkoznak-e vele, foleg, ha ennyire mimozak.#30 lev258: Javitjak boszen, mert egy oriasi bughalmaz, nem vagyok vele egyedul. Lasd 5.14-es kernelben mit ossze patchelik, van jopar fagyasos hiba: [link] Nalam is ilyenektol fagy a 3700U-s laptop. Konkretan monitor radugastol, lehuzastol is, de olykor videolejatszastol is. kernel msg-ben pedig latszik, hogy amdgpu-nal jon az oops/fault.
[ Szerkesztve ]
-
#94257664
törölt tag
Nem azt allitottam, azt allitottam hogy egy jelentes miatt van (ezek yzerint vol) perben, ahol nem voltak oszintek azzal kapcsolatban hogy mennyi volt a crypto jovedelmuk.
Ez erre a press release-re is igaz, mert a cryptot itt ugyanigy meg sem emlitettek annak ellenere hogy jelentos beveteluk volt belole, es valoszinuleg a gamingbe szamoltak bele most is, szerintem ertheto. -
válasz
#94257664
#24
üzenetére
már akkor is kiközölték és azóta is kiközlik a SEC fele tett jelentésekben . 10 hónapot érint a per amikor nem volt egyértelműen kiközölve a crypto bevételi szerepe.
[ Szerkesztve ]
"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)
-
#94257664
törölt tag
Egyrészt épp per alatt van az NVIDIA ezen jelentés miatt, (pont a Gaming rész kapcsán), másrészt a revenue nem egyenlő nettó profittal, harmadrészt az a helyzet, hogy a HPC és Data center eszközök egyenként sokkal drágábbak, még az egy az egyben ugyanazon GPU-t használó gaming GPU-k hiperinflált árai is eltűnik mellettük, sokkal magasabb a haszonkulcs egy Tesla vagy Quadro kártyán mint egy gamer kártyán, ami ezeknek a nyesett változata.
Illetve az elmúlt 2 év különleges helyzet volt a gaming gpu-k kelendőségének szempontjából (ennek okához kapcsolódik a per), de attól még hogy volt egy ilyen aranyláz, ami látszólag egyelőre alább is hagyott egy kicsit, nem lehet hosszú távú terveket építeni a cryptora.
A HPC-re igen, arra mindig szükség lesz. -
#20
fatpingvin
addikt
buherton
#18
fatpingvin
addikt
ott a forrásmegjelölés: tippre. amúgy a Talos II teljesítményadataira alapozom hogy miként viszonyultak anno a kortárs x86 designokhoz a lényegesen kisebb R&D tőkéből fejlesztett P9 Sforza procik.
dddekany: de, az. nézd meg mennyi tényleg totál felesleges csontváz van benne még a legmodernebb x86 procikban is.
az x86 design elemek felét ki lehetne hajítani a procikból és pontosan ugyanazt a modern funkcionalitást tudnák.
és igen, baromira nem tesz jót a versenynek hogy különböző zárt ajtók mögötti trösztmegállapodásokkal lényegében kényszerrel pozícióban tartják.
[ Szerkesztve ]
A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)
-
#19
ddekany
veterán
fatpingvin
#12
ddekany
veterán
válasz
fatpingvin
#12
üzenetére
Műszaki oldalról annyira nem nagy kiszúrás az x86 (azaz x86-64) ISA, főleg mostani CPU-knál, ahol a ISA-tól jobbára független alapvetőbb nehézségek leküzdésére megy a tranzisztorok java. OK, ronda, meg van némi pazarlás, de 2,5-3x-os gyorsulási lehetőségről szó nincs. Olyan szempontból kiszúrás, hogy korlátozza versenyt. Nem szabad saját mikróarchitektúrával kijönni, vagy SoC-ot építeni, amiben x86 magok vannak.
-
#18
buherton
őstag
fatpingvin
#12
buherton
őstag
válasz
fatpingvin
#12
üzenetére
tippre azt mondanám hogy a mostani számítási teljesítményekhez képest olyan 2.5-3x előrébb lennénk
Ezt mire alapozod?tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!
-
#16
dabadab
titán
fatpingvin
#11
dabadab
titán
válasz
fatpingvin
#11
üzenetére
az kicsit fáj hogy a Turingnál régebbi vasaikra marad a zárt modul.
Az így is fog maradni: az új driver erősen épít arra, hogy van GPU System Processor, az meg csak Turingtól kezdve van.
DRM is theft
-
Túl kevés, túl későn...
https://www.coreinfinity.tech
-
Czeky
Arcképgyáros
bocsánat a nagy betűkért, de VÉGRE!
HOGY ÉN MIÓTA VÁRTAM MÁR HOGY EZ BEKÖVETKEZZEN!
Gondolom az első driverek még nem lesznek bugmentesek, de örülök hogy végre az Nvidia is sokkal nyitottabb lett a Linux rendszerekre (gondolom főleg a Linux alapú gépek miatt teszi ezt, lásd Steam deck vagy Nvidia Jetson)
So you think it's really good, yeah? You should try making the bloody thing up; it's a real pain in the arse.
-
#12
fatpingvin
addikt
E.Kaufmann
#5
fatpingvin
addikt
válasz
E.Kaufmann
#5
üzenetére
a jóisten óvja meg a piacot attól hogy a GPU piac is ugyanazt az elk*rvulási útvonalat járja be mint ami a CPU architektúrákkal történt, hogy az amúgy technikai szempontból szuboptimális és érdemtelen x86 elfoglalja a piacot pár cég lobbitevékenysége okán.
nagyon erősen érdekelne hogy mennyivel előrébb tartanánk ha ugyanez a fejlesztési potenciál nem az x86ra pazarlódott volna hanem mondjuk a POWER, a SPARC és az Alpha kapja. tippre azt mondanám hogy a mostani számítási teljesítményekhez képest olyan 2.5-3x előrébb lennénk, az x86 meg maradhatott volna a beágyazott rendszerekben ahová eredetileg szánták.A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)
-
#11
fatpingvin
addikt
fatpingvin
addikt
ezt se hittem hogy megérjük
mondjuk az kicsit fáj hogy a Turingnál régebbi vasaikra marad a zárt modul.A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)
-
ricsip
addikt
Valószínűleg a múlt havi Lapsus hekkerek fenyegetése is közre játszhatott ebben. Azok ugye azzal fenyegetőztek h. ellopták a belsős szoftvereik nagy részét, és kipakolják publikusba az egészet. Esélyes hogy ezért húzódott sokáig ez a dolog, ment az egyezkedés a háttérben.
-
-
#8
dabadab
titán
E.Kaufmann
#5
dabadab
titán
válasz
E.Kaufmann
#5
üzenetére
Amúgy GPU-k esetén miért nem járható út egy (közel) egységes utasításkészlet, mint a processzoroknál
Mert egyelőre egy fix ISA nagyon korlátozná a fejlődést.
Csomó minden szoftveresen van megoldva ezért is volt ennyire zárkózott eddig az nVidia?
Igen, de az továbbra is zárt forrású marad.
DRM is theft
-
buherton
őstag
Idézet a cikkből:
A jelenlegi adatokból az látszik, hogy az NVIDIA a változást leginkább az adatközpontok miatt léphette meg, mivel ott zárt szoftveres háttér mellett tényleg problémaforrás lehetett például a TensorFlow használata, ami üzletileg szimplán nem kedvező.
A TensorFlow a Google machine learning toolja és igen csak széleskörben használt. Ráadásul ma már mindent is machine learning-el akarnak megoldani.
tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!
-
#5
E.Kaufmann
veterán
#94257664
#3
E.Kaufmann
veterán
Amúgy GPU-k esetén miért nem járható út egy (közel) egységes utasításkészlet, mint a processzoroknál (legalább is PC-n, de legalább, ha van nyílt forráskód, mindenféle driver nélkül fordítható közvetlenül adott utasításkészlethez a kód)? Csomó minden szoftveresen van megoldva ezért is volt ennyire zárkózott eddig az nVidia?
Le az elipszilonos jével, éljen a "j" !!!
-
-
#94257664
törölt tag
Nem, az NVIDIA-nak a Steam Deck es a tobbi jatekgep alapvetoen nem is piac, ezt a lepest odaszantak ahova valojaban nagy eladasaik vannak - HPC, kutatas, szerverek, cloud gpu kapacitas. Itt jellemzoen Linux rendszerek vannak mert fontos a stabilitas es a testre szabas lehetosege.
A gaming egy labjegyzet ezen cegek szamara mert egy retegigeny, a PC-s gaming ezen belul meg egy kis hanyad, a Linux PC gaming meg ennek a kis hanyadnak is kevesebb mint 1%-a
Mellesleg ezeken a jatekgepeken nyugodtan lehetett volna zart driver, senkit se erdekelt volna.[ Szerkesztve ]
-
#94257664
törölt tag
Remélem a Nouveau megoldja hogy ez a nyílt kernel modul együtt tudjon működni a saját userlandjükkel - ettől még valószínűleg soha nem lesz NVIDIA kártyám, de azoknak akik olyan szerencsétlen helyzetben vannak hogy a zöldek kártyáit kell Linux alatt használni, ez nagy segítség lehet majd.
Nem feltétlen csak azért maradt a userland zárt, mert sok shim / köztes kód van a többi rendszerrel, hanem userlandből limitálják a "butább" kártyák képességeit (VGPU, Encode stream limit).
El nem tudom képzelni mi szívás lehetett egy potenciális kernel upgrade egy ilyen, a forrást telebarmoló cuccal.
A modern Linuxokon az AMGPU/i915 modult beleforgatva a kernelbe és feltéve a Mesa-t, szinte plug and play megy mindkét nagyobb konkurens kártyája.
(Mielőtt ez ijesztőnek tűnne, a disztrók csomagkezelői ezt megcsinálják a user helyett).
![;]](http://cdn.rios.hu/dl/s/v1.gif)
? Adtak is meg nem is? 
Mire találtam egy kernel-driver párt, amin az opencl rendesen működött, majdnem kihullott a hajam, és ez a 334 + 5.4.x. Elvileg a 390-ben is tökéletesen támogatott a hardverem, de a valóságban mégis szétomlik a fenébe, pedig az összes létező keresztfüggést darabonként átnéztem... Szóval beragadtam egy ezer éves kernelbe a kurva nvidia meg a zárt forrású szara miatt. 
Új hozzászólás Aktív témák
Hirdetés
ph A vállalat megnyitotta GPU kernelmoduljait, ami Linuxon sokat javíthat a hardvereik használhatóságán.
- AKCIÓ! Sapphire NITRO+ RX 5700 XT 8GB videokártya garanciával hibátlan működéssel
- BONTATLAN! ASUS ProArt GeForce RTX 4070 OC 12GB GDDR6X Videokártya! BeszámítOK
- Asus Tuf 3080ti 12gb
- Pcie 5.0 ATX 3.0 12Pin - 16Pin Moduláris Kábelek És Adapterek 12VHPWR 12v2x6 Egyedi Harisnya Nvidia
- BESZÁMÍTÁS! MSI GAMING X TRIO RTX 3070 8GB videokártya garanciával hibátlan működéssel
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest