- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- iPhone topik
- Samsung Galaxy A56 - megbízható középszerűség
- Motorola Edge 50 Neo - az egyensúly gyengesége
- Átlépi végre az iPhone az 5000 mAh-t?
- Okosóra és okoskiegészítő topik
- Minden a BlackBerry telefonokról és rendszerről
- Magisk
- Nem növel telepméretet a Galaxy S26 Ultra
- iOS alkalmazások
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
válasz
Busterftw
#53
üzenetére
Azért ne vidd túlzásba. Az egy dolog, hogy hibásan tudod, és valószínűleg már rájöttél, de azért még terelsz, hogy mindenki hülye csak te vagy helikopter. Az pedig egy másik, hogy megpróbálod úgy beállítani, hogy neked van igazad. Előbbi csak az okosabbak szopatása, míg utóbbi konkrétan hazugság.
-
CPT.Pirk
Jómunkásember
Azt hiszem ez a poszt okozhat félreértést:
https://youtu.be/M42qWWi4y6k?t=848A megfogalmazás eléggé megtévesztő, mert csak a második bekezdésben írja, hogy nVidia Firmware-en keresztül működik a dolog a nyílt nvidia driverben, de még ott is kicsit zavaros a megfogalmazás.
-
Abu85
HÁZIGAZDA
Igazából a különbség az, hogy a HDMI működése hol van implementálva. Az AMD a driverben implementálja, míg az NV a firmware-ben. Ettől egyébként nem lesz valami hardveresen gyorsított, csak máshol van a kód. Viszont ettől a firmware az NV-nél zárt, tehát azért nem gond a HDMI Forum részéről, mert a kommunikáció az megtörténhet nyílt formában, de az implementáció ettől még zárt marad.
#47 Busterftw : Lassan leeshetne, hogy amiről te beszélsz, az nem létezik. Az előző két hsz. is erről szólt, és az is, amit eddig írtam neked. De persze te kötöd az ebet a karóhoz, miközben bizonyítékok tucatjait kaptad az ellenkezőjére. Pikari konkrétan megkereste neked azt a kódrészletet, ami bebizonyítja, hogy az alapállításod helytelen.
-
#47
Busterftw
nagyúr
fatpingvin
#46
Busterftw
nagyúr
válasz
fatpingvin
#46
üzenetére
A kernelben implementalva van a megoldas.
En nem beszeltem fentebb masrol, visszaolvashatod.Aztan hogy Abu mit hallucinalt es mit keresett, arrol majd o nyilatkozik.
-
Pikari
veterán
Közben megnéztem az nvidia hivatalos forráskódjában, mivel mindenki beszél róla, csak nem nézi meg:
Nem maga a hdmi protokoll van leimplementálva a driverben, hanem az nvidia hardveres hdmi implementációjával való kommunikáció, lebontva az nvidia hdmi implementációira több generációra visszamenőleg. A hdmi működését belülről pedig a hardver (hardveresen gyorsítva) végzi. Legalábbis ennyit tudok megállapítani az alapján, hogy az életemből erre 30 másodpercet rászántam.
-
#43
fatpingvin
addikt
Busterftw
#42
fatpingvin
addikt
válasz
Busterftw
#42
üzenetére
oké, szerintem ennyi bizonygatás után úgy hogy nem tudtad meglépni azt a triviális dolgot hogy linkeled a bizonyítékot, mindenkinek lejött hogy csak összevissza beszélsz.
függetlenül az állítás igazságtartalmától. aki bizonyíték alapján tudja hogy igaza van az első adandó alkalommal hivatkozik, nem pedig ismételgeti hogy márpedig úgy van mert én azt mondom de nézzél utána te.
-
Abu85
HÁZIGAZDA
válasz
Busterftw
#37
üzenetére
És azt a Phoronix cikk le is írja, hogy azért tudják megoldani a Nouveau driverben, mert elég csak meghívni a zárt firmware kódját hozzá. De ettől a kód nem lesz nyílt. Pontosan ezért akarom, hogy nézd meg a nyílt kódot, hogy lásd benne azt, hogy nincs benne olyan, amire utalsz. Én tudom, hogy nincs benne, mert láttam, de te szerintem még nem nézted meg, csak mondod, hogy ott van benne.
-
#40
Pikari
veterán
fatpingvin
#36
Pikari
veterán
válasz
fatpingvin
#36
üzenetére
Az ethernet vezérlőbe nem a tcp/ip protokoll van belegyógyítva, hanem az ethernet protokoll. Pár millió tranzisztor mindösszesen
Ezért hívják ethernet vezérlőnek -
#37
Busterftw
nagyúr
fatpingvin
#33
Busterftw
nagyúr
válasz
fatpingvin
#33
üzenetére
Ott a link, ha nem talalja az nem az en bajom. A Phoronix cikk is arra hivatkozik, ahogy a Nouveau driver hir is.
A levegot Abu korul ne linkeljem, azt se latja?Ha nem ert hozza akkor fejlessze magat.
A CUDA hirt sem frissitette, amit uj korlatozasnak hangoztatott, ami nem az. -
#36
fatpingvin
addikt
Pikari
#35
fatpingvin
addikt
a fizikai transcieverek lehet, de maga a HDMI mint protokoll az nem feltétlenül.
ez kicsit olyan mintha azt mondanád hogy egy Ethernet vezérlőbe bele van gyógyítva a TCP/IP protokoll. oké, lehet hogy van benne checksum offload engine, de nem ettől fogja tudni a TCP protokollt. -
#35
Pikari
veterán
fatpingvin
#33
Pikari
veterán
válasz
fatpingvin
#33
üzenetére
Eleve ez nagyrészt tranzisztor szinten van belegyógyítva a chipbe.
-
#33
fatpingvin
addikt
Busterftw
#30
fatpingvin
addikt
válasz
Busterftw
#30
üzenetére
nem azért de ebben a helyzetben már csak a praktikum szempontjából is rajtad van a bizonyítás felelőssége.
te azt állítod hogy van a kódban egy ilyen részlet, Abu azt hogy nincs. Abu linkelte a teljes kódot, demonstrálandó az említett kódrészlet hiányát. ha van ilyen blokk, tényleg csak annyit kéne tenned hogy ideírsz két pozitív integert, amik alapján a naiv szemlélődő megtalálhatja a forrásban hogy hol van a kérdéses kódrészlet amire hivatkozol. -
inc3gnito
csendes tag
Én Fedora Linux 39 alatt játszok Steam en keresztül ( Proton Experimental alatt). Tökéletesen működik minden rx 6600xt vel ryzen 5 5600x el. Minden game tükörsimán megy. Mangohud szerint ugyanolyan gyors mint win 11 alatt. A büdös életben nem térek vissza a Windows hoz. Programozáshoz is sokkal jobb a linux( bash, Visual studio code+github). Python3 fejlesztéshez .
-
-
Abu85
HÁZIGAZDA
-
#24
Busterftw
nagyúr
fatpingvin
#23
Busterftw
nagyúr
válasz
fatpingvin
#23
üzenetére
En amugy azt vartam epp az Nvidia miatt, amikor 2018-ban bejelentettek a big format gaming teveket, hogy ez majd ad egy lokest a DP elterjedesenek TV fronton.
Aztan nem nagyon jott be... -
-
Abu85
HÁZIGAZDA
A HDMI működésének implementációja eltér az AMD-nél és az NV-nél. Az AMD a driverbe rakja a vezérlést, az NV meg a zárt firmware-be. Emiatt ugye az NV-nek ez működhet NVK-val is, mert a kritikus kód mindig zárt marad.
#7 hapakj : Mindenkinek dedikált hardverei vannak sugárkövetésre, hiszen másképp olyan lassú lenne a teljes folyamat, mint WARP12-vel, ami vállalhatatlan. Az AMD bejárást az ALU-n akarja megoldani, ugyanis ha dedikált hardveren oldják meg, akkor az nem lesz programozható. A konzolokon ez alapkövetelmény, az nem egy PC-s mintát követ, ott azért több nagyságrenddel jobbak a sugárkövetésre vonatkozó programozhatósági lehetőségek. Viszont pont a konzolos API-k miatt a dedikált traversal egység nem jó, mert az a programozhatóságot akadályozza. Ebből egyébként lesz PC-s verzió is traversal shader néven, ami nem tudja hasznosítani a traversal unitot, mivel ennek a részegységnek a next gen DXR API-ban már nem lesz haszna. A bejárás át lesz rakva az ALU-kra, és onnantól kezdve az a hardver lesz gyorsabb, ahol az ALU-k működése van bejárásra szabva. Ez majd azt eredményezi, hogy idővel eltűnik a traversal unit a hardverekből, ahogy a T&L részegység is eltűnt. Most alapvetően a sugárkövetés ott tart, ahol a T&L tartott anno, és a következő kör a programozhatóság. Ez egyébként jó dolog, mert növeli a sugárkövetés használhatóságát, nem csak alig észrevehető teljesítményt pazarló effektekre költhető el az egész. Lásd például az új Avatar, ami konkrétan hozzá sem nyúl a hardverekben található traversal egységekhez, mert szoftveresen oldja meg ezt compute shaderrel. És mégis messze a leggyorsabb sugárkövetést látjuk benne, pont azért, mert maguknak programozhatóvá tették a bejárást, így nem kell a hardverek korlátozott és rém pazarló működésére alapozniuk. Ezt a jövőben több címben látni lehet majd, mert annyira limitáló a traversal unit a lehetőségek tekintetében, hogy többen is elkezdték járni azt az utat, amit az Ubisoft. Ha a Microsoft nem ad még programozható bejárást, akkor megcsinálják maguk compute shaderrel.
A modernebb GPU-kban vannak AI-ra szabott feldolgozók. Az AMD, az Intel és az NV GPU-kban is. A különbség annyi, hogy mennyire erőltetik a cégek ezt a vonalat. Gamingnél sok haszna nincs, mert ezek a feldolgozók ugyanazokból a regiszterekből esznek, vagyis ha használva vannak, akkor csökken az occupancy, hiszen a normál ALU-k ugyanazt a shadert jóval kevesebb regiszterterületbe tölthetik be, vagyis joval kevesebb konkurens wave-et futtathatnak. Emiatt van az, hogy egy játékban alig nyúlnak a tensor magokhoz, mert drasztikusan növelné a regiszternyomást, ami végeredményben az általános számítások teljesítményét csökkenti azzal, hogy a GPU nem tudja optimálisan átlapolni az elérési időt. Ez a jövőben sem változik meg, mert meg kellene duplázni legalább a regiszterek méretét, hogy a GPU-k elkezdjenek profitálni egy játékban ezekből az AI-ra szabott ALU-kból, csak ennek a tranzisztorköltsége irreálisan magas.
Az OFA nem biztos, hogy célszerű. A legnagyobb gond vele, hogy a teljesítménye fixen limitált. Bármit is szeretnél javítani a frame-gen rendszeren, képtelen vagy megtenni, mert ott a hardveres limit, amit nem léphetsz túl. Ezért is érdekes a DLSS és az FSR frame-gen, ahol az a tipikus álláspont manapság, hogy az FSR-felé képgenerálás még jobb is. De nem azért, mert az AMD ügyesebb volt, hanem azért, mert az AMD-t nem korlátozza egy OFA részegység teljesítménye, míg az NV-t igen, tehát nem tudnak előrelépni, csak a következő generációnál, ami jobb részegységet kaphat. Eközben az AMD pusztán szoftveresen fejlesztheti a kódot, mert asszinkron lefut compute shaderben, és ALU-ból van egy rakás a mostani GPU-kban. Annyira sok szabadon használható kapacitás van a középkategóriás GPU-kban is, hogy az már most lekörözi az OFA részegységben lévő teljesítményt. Emiatt van az, hogy az NV is elkezdte ezt az irányt kutatni, mert ők is limitálónak érzik azt, ha csak generációváltásonként tudnak ugrani frame-gen minőséget, ami kb. kétévente van. Konkrétan rendelkeznek már egy olyan kóddal, ami úgy működik, ahogy az FSR frame-gen, és a vicc az, hogy a Palittól tudom, hogy már most jobb az eredmény úgy, hogy nem nyúl az OFA részegységhez, csak még nincs kész a projekt. Ráadásul ez a projekt mehet a driverbe is egy AFMF alternatívaként. Szóval az OFA az nem egyértelmű helyzet. Ott azért nagyon sok limitáció van hardverből, ami korlátozza a szoftveres lehetőségeket.
-
Pikari
veterán
A nouveau is nagyon gyorsan fejlődött az elmúlt pár évben. Onnan indultunk, hogy fél óránál tovább stabilan webet böngészni se nagyon lehetett vele, mert rommá fagyott a gép. Ilyen gondok ma már nincsenek. Amivel súlyos gondok vannak, azok a teljesítményszintek közötti váltás egyes gpu generációk esetében, a kártya általában idle profilban ragad, és nem lehet onnan átváltani.
-
Busterftw
nagyúr
-
hapakj
őstag
háááát, nVidiában dedikált egységek vannak Ray Trace-re (mind a Accelaration Structure építésre, mind a konkrét raytrace-re), tenzor feldolgozásra és a Lovelace-ben opticalflowra a DLSS 3 frame generationhöz. AMD mindezt ALU erőből akarja megoldani, s szemmel láthatóan szarul is megy
.
Raytrace-re már beraktak valami hw-et, de asszem a BVH építés még mindig az ALU-n megy. -
JohnyX
tag
Ezt az adatot hol találtad a Steam HW felmérésben?
Én ezt találtam, de ebből nem derül ki a használt VGA típusa:
LEGNÉPSZERŰBB / SZÁZALÉK / VÁLTOZÁS
Linux / 1.76% /-0.19%
"Arch Linux" 64 bit / 0.14% / -0.01%
Ubuntu 22.04.3 LTS 64 bit / 0.09% / -0.04%
Linux Mint 21.3 64 bit / 0.06% /+0.06%
"Manjaro Linux" 64 bit / 0.06% / -0.01%
-
CPT.Pirk
Jómunkásember
Na igen, a Deck-ről megfeledkeztem, pedig nekem is van.
Így van, ahogy írod. Viszont ennek örülünk, mert ebből mindenki profitál.Látva az NVK gyors fejlődését, mondjuk mához 2 évre tényleg ott leszünk, hogy egyik gyártó kártyájához sem kell majd semmit sem csinálni Linux alatt, egyszerűen csak működni fognak.
Azt mondjuk nem tudom, hogy a hdmi-forum merev elzárkózása a hdmi2.1 nyílt megvalósításától amivel most az AMD-nek intettek be, az érinti-e majd az NVK-t is. -
-
Abu85
HÁZIGAZDA
Az NVK azért lett fontos, mert az AMD teljesen leuralta az olyan piacokat, mint amit a Steam Deck teremtett. Az asztali részre szarik az NVIDIA, nem akar azzal semmit, de a Steam Deck egy kitörési lehetőség, csak addig szarik a Valve az NV-re, amíg legalább olyan szinten nem lesz az NV open source meghajtója, amilyen szinten van az AMD-é.
Nyilván itt még az is szóba jöhet, hogy a SteamOS 3.0 egy nagyon jól sikerült rendszer, és ki tudja, hogy a Valve mit akar még vele kezdeni. Viszont a mostani verziójában egy erősen AMD-only cucc, és ez nem a Valve-on múlik, hanem azon, hogy a többiek nem tették bele azt a munkát, amit az AMD.
-
-
CPT.Pirk
Jómunkásember
Ezt meglépte az AMD is, 9 évvel ezelőtt. Meg is lett az eredménye, mert mostanra meg a Steam HW felméréseinek adatai alapján az AMD GPU-k domininálnak a Linuxos gépekben. Ez mondjuk nem is csoda, mert fejből nem is tudok olyan esetet mondani, amiért neked kézzel kellene AMD zárt drivert telepíteni Linuxon... Egyszerűen csak felraksz egy disztrót és minden működik a nyílt driverrel, egyből mehet a Cyberpunk indítása, hogy csak egy példát mondjak.
A 2015 előtti években a helyzet fordítva volt, mert botrányosan tré volt az akkor még létező AMD Catalyst driver minősége Linuxon, olyan alap dolgok nem mentek benne, mint pl. a scaling csúszka pozíciójának elmentése...
Aztán időközben az nVidia zárt drivere bár jól működött, de az meg olyan, hogy van több kiadás belőle párhuzamosan, az adott kártya generációk szerint. Aztán ha jön egy döntés a support megszűnéséről, akkor onnantól x évnél régebbiekre már nem lesz működő, telepíthető zárt driver. A régi nyílt nvidia driver persze ott lesz továbbra is az EOL hardverek számára, szóval képet fognak adni a régebbi kártyák is, de úgy ennél sokkal többre nem kell számítani.
Nem igazán szeretjük az nVidiát, valahogy az egész cégen érződik, hogy az asztali játékos csak egy megtűrt kategória az AI meg egyebek mellett, mert azokból jön igazán a pénz... Gondolom az nVK nyílt driver is csak azért kapott zöld utat, mert látták az AMD sikerét ezen a téren és ha ez több eladott kártyát jelent, akkor ez nekik is kell.
Jó ökörnek lenni?
bár mókásabb lett volna ha a poén lelövésének lehetőségét meghagyod a kollégának ![;]](http://cdn.rios.hu/dl/s/v1.gif)
Ezért hívják ethernet vezérlőnek 
Új hozzászólás Aktív témák
Hirdetés
- ÁRGARANCIA!Épített KomPhone i3 10105F 16/32/64GB RAM RX 6600 8GB GAMER PC termékbeszámítással
- Telefon felvásárlás!! Apple iPhone 16, Apple iPhone 16e, Apple iPhone 16 Plus, Apple iPhone 16 Pro
- ÁRGARANCIA!Épített KomPhone i7 14700KF 32/64GB RAM RX 9070 XT 16GB GAMER PC termékbeszámítással
- Lenovo ThinkPad L16 Gen 1 - 16" WUXGA IPS - Ultra 5 135U - 16GB - 512GB - Win11 - 2,5 év gari
- Beszámítás! Apple Mac mini 2020 M1 8GB 256GB SSD számítógép garanciával, hibátlan működéssel
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest