- Motorola G86 - majdnem Edge
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- LG G8X - kettőn áll a vásár
- iPhone topik
- Mobil flották
- Google Pixel topik
- Fotók, videók mobillal
- Honor 400 Pro - gép a képben
- Android alkalmazások - szoftver kibeszélő topik
- Hat év támogatást csomagolt fém házba a OnePlus Nord 4
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
A licenceket bevallom nem nyálaztam át. Köszönöm, hogy kiegészítetted.
(#117) Jack@l: Az AMD az OpenCL támogatást pénzeli. Hardvereket és szoftveres támogatást adnak a projekt fejlesztőinek, illetve anyagi hozzájárulást, hogy a munka zavartalan legyen. A projektet korábban az Intel és az NV is pénzelte a GPGPU-s irányért, de semmire sem jutottak. Teljesen normális, hogy az x264 erőforrásai limitáltak, és egy olyan cég, mint az AMD, ezen segíteni tud, hülyék lennének visszautasítani. Ugyanakkor az x264 projekt ettől független marad, így a fejlesztők egyéni döntéseket hoznak. Az AMD ebből úgy profitál, hogy a hardvereikre direkten optimalizálják a programot. Tipikus win-win szituáció, és ettől a konkurens hardvereket sem kell a háttérbe szorítani.
Az AMD-nek van egy alternatív partnerprogramja, de az egészen egyedileg épül fel, és olyankor a program olyan módosításokat kap, hogy csak az AMD hardverekkel üzemképes. Az x264 ebben nem vesz részt. -
-
Abu85
HÁZIGAZDA
Most az x264-ről van szó. Annál a lookahead van átrakva GPU-ra. A minőségi különbségek még komoly elemzés mellett sem észrevehetők. Ha azok lennének, akkor nem válna az OpenCL-es x264 az elsődleges platformmá. Most pont azon dolgoznak, hogy az OpenCL-es verzió a C-shez képest jobb minőségű legyen.
Három lépcsőben támogatja a projektet az AMD. Az első, hogy legyen egy OpenCL-es verzió, aminek a minősége lényegében megegyezik a C-s verzióval. A második, hogy legyen a minősége jobb, míg a harmadik, hogy legyen egy verzió, amit a Kaveri APU új képességeihez készítenek. Most az első és a második lépcső között vagyunk.
Majd novemberben meglátjuk mire jutottak. Akkor az AMD developer rendezvényén újra lesz előadásuk. -
Jack@l
veterán
Amiről julius is beszélt az aza akar lenni (feltételezem) hogy szep dolog a sebességnövekedés, csak ezt úghy érik el a mostani opnecl-es és cuda-s tömörítők, hogy pár feldolgozási részt kihagynak a workflow-ból, ezáltal közepes minőséget tudnakl csak elérni. Amit persze pistike nehezen lát meg a gépén, de minőségropmlás attól még lesz.
-
Abu85
HÁZIGAZDA
válasz
julius666
#108
üzenetére
Ezek a képek vannak most. Az biztosan állíthatom, hogy saját tapasztalatomból is igen jó a GPU-s minőség. Gyakorlatilag nem látok különbséget a C-s x264-hez képest. Pedig a beállítások megegyeztek.
A hivatalos anyagokban is ilyen gyorsulásokról számolnak be, ezért hittem én is a saját méréseknek. Tekintve, hogy az OpenCL-es x264 lesz az elsődleges platform, gondolom ők is több jövőt látnak benne, mint a C-s verzióban.
Én is hitetlen voltam. Ezekkel még nem dolgoztunk sokat, csak megnéztem őket, hogy hogyan működnek, mert 2013-ban egy csomó OpenCL alkalmazást felveszünk a tesztekben. Ezeket nem lehet csak úgy bedobni, mert ha később szívunk vele, akkor az gáz a tesztre nézve, így előre ki kell tesztelni, hogy melyik hogyan működik, mennyire stabil a mai OpenCL-es driverek mellett. Az x264-ről a legjobb a véleményem a stabilítást tekintve, és nem problémázik a gyártón. Van erre ellenpélda is, ami így nem téma a tesztelés szempontjából.
-
julius666
addikt
Az összehasonlító képek a beállítások megadása nélkül nem érnek sokat. Ha elég bitrátát kapnak, a dzsunka H264 tömörítő és az x264 között ugyanúgy nem látni a különbséget. Veszteségesen tömörített képet használni összehasonlításra meg külön lol.
Sajnos videótömörítő teszt esetén nagyon könnyű csalni. Aki látott már marketinganyagokat tudja miről beszélek, screenshot alapján gyakorlatilag csak x264-verő enkóderek vannak a piacon.
No offense, még csak nem is feltétlenül tudatos sumákolásról beszélek, egész egyszerűen ahhoz, hogy legalább nagyjából objektív tesztet végezzen az ember, eléggé érteni kell hozzá és itt nem csak a PH-s részéről beszélek, hanem magáról a videós világról is. Ez nem olyasmi hogy megnyomod a 'run' gombot a bencsmárkban és kiköp egy számot. A laikusok által végzett tesztek inkább csak e-pénisznek, meg reklámanyagokba parasztvakításnak jók sajnos.A mért értékeket nem vagyok képes elhinni, sajnos mostanság nincs nagyon módomban kipróbálni, de majd megpróbálok jobban utánaolvasgatni ha lesz időm doom9-en mások mire jutottak. Biztos hogy ugyan azokkal a beállításokkal mértetek? Nem lehet hogy a CPU-s mérésnél valami bezavart a képbe?
Tudom hogy elég rosszul veszi magát, hogy mutatsz konkrétat és én abba is belekötök és respekt hogy dolgoztatok vele, de még egyszer, ha nem csak 2 CPU összehasonlítására használjátok a x264-et benchmarkként, akkor messze nem olyan egyszerű a képlet.
-
#107
hugo chávez
aktív tag
Abu85
#103
hugo chávez
aktív tag
Hát ez nem volt könnyű szülés...
(#105) lenox:
"Amugy eleg fura az intel is ezzel az sse/sse2 es avx/avx2-vel, ugyanazt eljatszak, pedig szerintem mar az elso korben is kiderult, hogy kell az integer is."
Csak nem lőhette el az Intel az AVX2-t az Ivy-nél, hogy illett volna az a "tick"-be?
A Sandy-be meg talán a még 32 nm miatt nem került bele, talán akkor túl nagy lett volna a fogyasztás... -
lenox
veterán
Az x264 szempontjából az AVX2-es OpenCL verzió 55%-kal gyorsabban fut Haswellen csak CPU-val, mint az AVX2-es C-s verzió.
Lehet, hogy igy van, de akkor a c verzio nem tul jo. Ugy ertem az opencl cpu-ra cpu kodot fordit, szoval lehetne azt hasznalni, ha a kezzel irt c nem olyan jo. Amugy eleg fura az intel is ezzel az sse/sse2 es avx/avx2-vel, ugyanazt eljatszak, pedig szerintem mar az elso korben is kiderult, hogy kell az integer is.
-
Abu85
HÁZIGAZDA
Most már az is jó.
Ez így van meg. A lényeg látszik. Nem tudod megmondani, hogy melyik a szebb.
Ma itt tartunk, és a következő körben szebbre ígérik az OpenCL-es verziót, noha igaz, hogy ez a modul lassulni fog. A jövő szempontjából ez a verzió lesz az elsődlegesen fejlesztett platform, míg a C-s a másodlagosan fejlesztett.
Az AMD, az Intel, és lassan mindenki más úgy alakítja ki a hardvereket, hogy OpenCL-ben lehet ezeket a legjobban kihasználni. Az x264 szempontjából az AVX2-es OpenCL verzió 55%-kal gyorsabban fut Haswellen csak CPU-val, mint az AVX2-es C-s verzió. Erről volt egy Intel előadás, hogy az AVX2 OpenCL-ben jóval hatékonyabban használható, és a vállalat erre szeretné terelni a fejlesztőket.
Többek között a Havok motor esetében is a GPU-s gyorsításra szabott FX verzióban lesz AVX2 támogatás.
Megváltoztak a fejlesztési irányok. Az OpenCL elvi működése az ilyen 256-512-1024-2048 bites SIMD-eknél jelentős fegyvertény lett ... mindegy, hogy CPU vagy GPU. -
#101
Abu85
HÁZIGAZDA
hugo chávez
#97
Abu85
HÁZIGAZDA
válasz
hugo chávez
#97
üzenetére
Én rontottam el. A CPU-snál az OpenCL-est töltöttem fel a sima helyett. Most már jó.
-
#98
F34R
nagyúr
hugo chávez
#97
F34R
nagyúr
válasz
hugo chávez
#97
üzenetére
vajon miert ? intel quick sync.
-
Abu85
HÁZIGAZDA
válasz
julius666
#92
üzenetére
Akkor pár eredmény:
Referencia , CPU , Radeon , HD Graphics , GeForceBámulatos munkát végeztek szerintem. És, hogy melyik a szebb? Én nem tudnék dönteni.
Ahhoz képest, hogy csak a lookaheadnek kellene ennyit gyorsulnia csak egy eredmény egy A10-4600M-ről. CPU-val 6,9 fps, míg GPU-s gyorsítással 15.
Ez a hivatalos mérés.
A 40-60%-ot azért mondtam, mert asztali Trinity APU-kon ennyi a tényleges előny, amit házon belül mértünk.2012 közepén voltak elképzelések. Most már a kivitelezésnél tartanak. Az OpenCL driverek szempontjából a fejlesztők az AMD-hez igazodnak. A többiek majd felveszik a tempót, ha akarják. Mivel a projektet nagymértékben pénzeli az AMD, így ez logikus döntés. De ahogy elnézem az x264 aktuális verzióját nem veszem észre, hogy a többi hardvernek nem tetszene. Pedig ez a program csak béta, és azon kevés OpenCL alkalmazások egyike, amely még nem cirkuszolt hardver vagy driver miatt.
(#95) MaUser: A vezető fejlesztő állítását írta le Lenox.
-
MaUser
addikt
Négy eset lehet:
- a 20+ ember a három hónap alatt írt 10.000-20.000 sor kódot, azt sem túl tömören
- kevés modul-ból áll a projekt
- a már korábban fordított object file-ok is benne voltak a letöltött részben, ezért a fordító csak újra linkelt
- valamikor nyomott rá egy build-et, de amikor nézte az időt, már csak egy inkrementális fordítás ment le
- a projekt build-je nem fordítja újra az egészet (vagy nem állította be), hanem dll-eket linkel csak összeEgyébként command prompt-ból indított fordítás, több szálon engedélyezett fordítás (nyilván ennek igazán több külön projektnél van értelme egy solution-ön belül), file log console log helyett csodákat tud tenni. Van amikor 10-20X-os a gyorsulás. De ez VS only. Egy TI compiler-nél sokra nem megy ezzel az ember.
@lenox: Ha manager írta, akkor:
'quality is on par with C version of x264' -> fél szemmel nézve három sör után még hasonlít is rá
'quality is equal to C version of x264' -> majdnem hasonlít
'quality is exactly the same as C version of x264' -> hasonlít, de a kutyám életét azért nem tenném rá
'quality superseeds C version of x264' -> ugyanolyan a minőség, csak kétszeres a file -
-
julius666
addikt
A nem végleges, de aktuális verzió esetében a fejlesztők garantálják, hogy ugyanazt a minőséget kapod, mint a CPU-s verzióval.
Ez nem igaz. Nem kaphatod ugyan azt a kimenetet, mivel pl. a mozgásvektorok keresésére teljesen más algoritmust használnak, ami kevésbé precíz eredményt ad. Viszont mivel csak a lookaheadről beszélünk, ennek a végleges kimenetben minőség szempontjából kis szerepe van, így a minőségkülönbség gyakorlatilag elhanyagolható, pár %. De nem megegyező.
A lookahead GPU-s gyorsításával konkrét eredmény, hogy egy APU nagyjából 40-60%-ot gyorsul, míg HD 7970-nek kétszeresére nő a sebesség.
Igen, a lookahead tényleg ennyit gyorsul, viszont az az egész tömörítési folyamatnak csak egy apró töredéke, a tömörítés idejének olyan 10-20%-át jelenti. Szóval ez a 10-20% csökken úgy 40-60%-al, így jön ki összességében az a "jó esetben 10%-os gyorsulás" amit írtam.
Ezt a "40-60%-os gyorsulás"-t ne terjeszd nagyon legyél szíves mert ez így ebben a formában nem kicsit csúsztatás.
Jelenleg azon dolgoznak, hogy a végleges verzió kész legyen, majd a következő körben, elérhető lesz olyan verzió is, ami már jobb minőséget fog adni a CPU-snál. Erre a lookahead GPU-s gyorsítása lehetőséget ad. Ez opcionálisan lesz bekapcsolható. Természetesen a jobb minőség sebességbe kerül majd, de az aktuális tesztverziók szerint számos rendszerrel még így is gyorsabb lesz a konvertálás, mint a CPU-s verzióval.
Igazából még csak elképzelések vannak arról, hogy ha már ráeresztjük a lookaheadet a GPU-ra ami amúgy ott csücsül üresen akkor használjuk ki minél inkább, valami masszívabb algoritmussal. Konkrétan olyan hogy "ilyen meg ilyen verzió lesz" még nincs, csak a "majd meglátjuk". Amikor utoljára arrafelé jártam akkor még masszívan az azon való vért izzadás ment, hogy az egész a fejlesztő gépén kívül is működőképes legyen.
A csodás OpenCL driverek meg a GPU-k ugye, szép új világ, a debuggolás igazi APUkuntúrás kezelés tud lenni. -
Abu85
HÁZIGAZDA
válasz
julius666
#90
üzenetére
Igazából érdemes lenne a tényleges fejlesztéseket figyelembe venni. Az OpenCL x264 folyamatosan fejlődik. A nem végleges, de aktuális verzió esetében a fejlesztők garantálják, hogy ugyanazt a minőséget kapod, mint a CPU-s verzióval. A lookahead GPU-s gyorsításával konkrét eredmény, hogy egy APU nagyjából 40-60%-ot gyorsul, míg HD 7970-nek kétszeresére nő a sebesség.
Jelenleg azon dolgoznak, hogy a végleges verzió kész legyen, majd a következő körben, elérhető lesz olyan verzió is, ami már jobb minőséget fog adni a CPU-snál. Erre a lookahead GPU-s gyorsítása lehetőséget ad. Ez opcionálisan lesz bekapcsolható. Természetesen a jobb minőség sebességbe kerül majd, de az aktuális tesztverziók szerint számos rendszerrel még így is gyorsabb lesz a konvertálás, mint a CPU-s verzióval.
Az ennél is újabb fejlesztésekről novemberben beszélnek. Azokról nagyon keveset tudni. Az igazából nem GPU-ra készül, hanem kifejezetten a Kaveri APU-ra, és a működés szempontjából hasonló hardverekre. -
julius666
addikt
lehet-e gpura ugyanolyan minosegu videot encodolo programot irni. Szerintem lehet, sot bitrol bitre egyezot is lehet.
Hogy érted ezt? Hogy a teljes enkóder pipeline GPU-n fut? Mert még olyat se lehet. Vagyis pontosabban baromi lassú lesz, főleg ha ugyan azt az outputot akarod, amit a CPU köhög ki. Az aritmetikus kódolás pl. baromira nem fekszik a GPU jellegű feldolgozóknak, a jelenlegi GPU-s enkóderek ezt a fázist gyakorlatilag mind átdobják a procinak. Kivéve esetleg az ilyen fix funkciós vackok, de ott ugye igazából nem GPU-s tömörítésről van szó (ugye ebbe megint bele lehetne kötni ki mi alatt mit ért, mert nem mindegy).
De elolvastam amit Abu kuldott, ott is azt irtak, hogy ugyanolyan a minoseg, mint cpun, nyilvan megfeleloen valasztottak ki, hogy mit gyorsitanak pontosan gpuval.
Igazából nem tudom mit küldött neked Abu, a videóban elég jól elmondják mit gyorsítottak és miért. Az x264 pipelinejának az első, legegyszerűbb és a gyengébb feldolgozási lehetőségeket legjobban tűrő részét, a lookaheadet. A többi rész nem változott, CPU-n fut ugyanúgy, jó esetben ha gyorsul a lookahead GPU-n számoltatásától 10%-ot a tömörítés sebessége, minimálisan rosszabb kimeneti minőségért cserébe (mert nem egyezik a GPU-val gyorsított x264 kimenete a sima CPU-séval). Gyakorlatilag az egész inkább csak marketing, (az AMD-nek reklám, meg befogja azok száját akik évek óta az x264 GPU-s gyorsításáért sírnak) illetve egy jópofa tanulmány, mint valami ami valós gyakorlati hasznot is hoz. Legalábbis rövidtávon biztos.
-
lenox
veterán
Persze, hogy kevert modszert hasznal mindenki, nem is igen lesz sosem csak gpus, mert van amire egy cpu gyorsabb. De amit en allitottam es vitatkoztok vele az az, hogy lehet-e gpura ugyanolyan minosegu videot encodolo programot irni. Szerintem lehet, sot bitrol bitre egyezot is lehet. De elolvastam amit Abu kuldott, ott is azt irtak, hogy ugyanolyan a minoseg, mint cpun, nyilvan megfeleloen valasztottak ki, hogy mit gyorsitanak pontosan gpuval.
-
-
pakriksz
őstag
"Javaslom a négy legnagyobb hazai fejlesztőközpont külföldi anyavállalatának azonnali felkeresésest és magad degeszre keresését a javaslatoddal."
Tudod ahol ekcelt használnak adatbázis helyett, ott lehet javasolgatni, de nincs értelme, hiszen ha a helyi hülyék ilyet jóvá hagynak ott nincs helye érveknek
"sehol nincs kismillió xxSQL szerver" persze hogy nincs... tudod egy sql szervert egyszerre nagyon sok feladatra lehet használni
"Az meg hogy nem programozol látszik, szinte semmit nem számít a HDD sebessége sem parse-nál, sem fordításnál komolyabb kódnál." látom már ideges vagy, és kezdődik a kiforgatás. Programozom, csak nem natív programokat mint írtam.
"Az meg ugye megvan, hogy itt nem a te két perc alatt összerakott C# progidról van szó, hanem mondjuk egy "átlagos" beágyazott vezérlőprogramról 10000+ file-lal, ami egy 8 magos gépen is két órán keresztül fordul."
megint csak próbálsz szurkálni. komolyabb program nálam nem 2 perc alatt összerakható. Mondjuk amit próbáltam egy hónapokig 20+ ember által készített 3Ds szimulátor játék fordítása(ami ráadásul kompatibilis egy régebbivel, és maga a kompatibilitási réteg akkora kb mint a játék lényegi része). Ez volt 20 másodperc egy athlon II X4-en....
10000 ezer file egy nyamvadt fékvezérlőre azt hogy? minden betű külön fájlt kapott? ;D
Amúgy is irodáról volt szó. Az irodáai gépek 99%-ban nem programoznak, sem forgatnak kódot
-
Sinesol
veterán
+1
A cegnel ahol dolgozom most ujitottak a geppark egy reszet es vettek 2-3ezer darab i5-3470re epülö gepet..ha jol emlékszem talan lenovo vagy ilyesmi.
Na marmost nemtom egyebkent atlag usereknek mennyit adnak el itt intelt de nemhiszem hogy hasonlo nagysagrend..(es ez csak 1 a sok multi cegböl)
A gépeken egy alap monitorozo es diagnosztikai szoftver megy, altalaban munkaallomasonkent 1gep de sok allomasnal 4-6gep is tartozik egy emberhez 6 monitorral (nem eyefinity,mindegyik külön kepet ad de a monitorok 6os tablakban egybevannak epitve.
Par honapig rendben volt de mar most is panaszkodnak ra hogy a gepek lassulnak be...tehat megiscsak kell az i5.
Az IGP meg kb le van tojva képet ad ennyi a lenyeg..ebböl leszürhetö az hogy ahol jelenleg a legtöbb gepet eladjak ott nemigen törödnek az igp-vel. a pcs gamer kisebbseg aki meg jatszik az meg dGput vesz.
Annyit meg hogy a gepek amiota üzemben vannak vagy 2-3honapja 0-24oraban mennek, és aamig üzemelnek nemsokat lesznek lekapcsolva..ez elég kemény terhelés.
Ne kerdezzetek meik ceg mivel titoktartasi nyilatkozatbol alairtam egy parat es meg a nevet se lehet elvileg a ceg beleegyezese nelkül semmilyen mediaban emliteni. -
MaUser
addikt
nem az összes. Normális cégeknél bizony rendes adatbázis van. Ez az ekceles bohóckodás csak magyarországon terjedt el igazán, és igen, azért mert hülyék hozzák a döntéseket
Javaslom a négy legnagyobb hazai fejlesztőközpont külföldi anyavállalatának azonnali felkeresésest és magad degeszre keresését a javaslatoddal. Itthon ezekhez volt szerencsém, sehol nincs kismillió xxSQL szerver, ellenben Excel használat ezerrel, titkárnői szinten is. Azért, mert az 10 év múlva is jó, könnyen hordozható, stb. A rendelések követésétől az utazási processzekig ezen ment mindenhol minden, mielőtt szépen át nem pakoltak szinte mindent SAP-ba, az egyszerűbb dolgokhoz maradt az Excel. Gyártásba adásnál meg még mindig szinte de facto Excel tool-ok vannak. Szerintem szívesen veszik majd, ha a világszinten 30e+ fejlesztőmérnököt foglalkoztató vállalatnak megmondod a tutit.
Bár natívban régóta nem programozom, de egy komplex c# vagy java programot seperc alatt összerak egy brazos is, főleg mert inkább a HDD sebessége a szűk keresztmetszet ennél is.
Az meg hogy nem programozol látszik, szinte semmit nem számít a HDD sebessége sem parse-nál, sem fordításnál komolyabb kódnál.
Az meg ugye megvan, hogy itt nem a te két perc alatt összerakott C# progidról van szó, hanem mondjuk egy "átlagos" beágyazott vezérlőprogramról 10000+ file-lal, ami egy 8 magos gépen is két órán keresztül fordul. És ez semmi extra, csak egy nyamvadt kis fékvezérlő. Ne abból indulj már ki, hogy láttad Mancikát a helyi okmányirodában. Termelő cégeknél igen keményen használják a gépet, még sokszor titkárnői szinten is.visszakérdezek
Nyugodtan, de előbb a kérdésemre felelj kérlek. Mire kell a HD4000 az irodában?
és mihez nem elég egy atom proci egy irodában? ja és akkor elkezdesz sorolni olyan dolgokat amik az irodák 99%-ban nincs, vagy olyan marhasággal támasztod alá hogy i7 bizony kell, mint az elcseszett ekceltáblában tárolt adatbázis.
De ha már konkrét példát akarsz hát tessék: egy c2d-n (még csak nem is atomon!) a mostani projektem dinamikus és statikus kód analízise 7+ óra egyenként. Egy jobb i7-tel fél óra. Miért számít ez? Mert akár egy sor módosított kód feltöltés előtt ezeket futtatni kell (biztonságkritikus rendszer). Szerinted ha mind a párezer sw fejlesztő atomon nyomná, tudnának csinálni egyáltalán valamit?
Az a feltételezés hogy szerinted nem tud egyszerre több ember használni egy Excel táblát, meg egy vicc. 97-es Office-ban már volt beépítetten csoportmunka, belső verziókövetés (ez mondjuk használhatatlan szvsz).
-
F34R
nagyúr
nem-nem en is igy vettem eszre, egy halom szoftver meg a kevert modszert hasznalja mivel nem lehet csak a GPU-ra tamaszkodni (ezert nincs is egetvero kulombseg koztuk ) A minoseg egyertelmu hogy sokkal jobb CPU-bol , ezt is csak nagy surusegu RAW- vagy BD forrasbol kodolt anyagnal lehet eszrevenni (mar aki tudja).
Jo par evig meg bizonytalan lesz es javitani fognak egy halom hibat mire majdnem mindennel kompatibilsek lesznek. -
lenox
veterán
válasz
julius666
#75
üzenetére
Oke megnezem, de igy latatlanban az a velemenyem, hogy azert nem olyan sokkal gyorsabb a gpu encoding, mert nem idealis a gpu a feladatra, es azert nem olyan jo a minoseg, mert nincs kifejlesztve minden feature. A minoseg lehetne pont ugyanolyan is csak tul sok munka minden featuret kifejleszteni. De ha Abu elkuldi megnezem, mire hivatkozol.
-
pakriksz
őstag
igen üzemeltetnék. Egy meglévő szerveren egy néhány megás folyamatról szól az egész
amit pár perc alatt lehet telepíteni. Egyébként normális vállalatoknál eleve van jópár sql szerver, ahova befér +1 tábla "De simán lehet, hogy az összes cég hülye mert azon modulokat amiket nem SAP (vagy egyéb vállalatirányítási rendszer) keretében kezelnek és megoldhatóak egy 10-20mb-os Excel file-lal meg 10-20 scriptből, ahhoz nem lőnek fel egy xxSQL szervert meg valami thin client guit."
nem az összes. Normális cégeknél bizony rendes adatbázis van. Ez az ekceles bohóckodás csak magyarországon terjedt el igazán, és igen, azért mert hülyék hozzák a döntéseket
Az király lehet az ilyen ekceles bohóckodásnál amikor 2-en egyszerre módosítanak valamit a táblában
Persze lehet traktorral balatonra ruccanni, csak autóval azért jobb"Szerk: Irodában mihez nem elég - nem hogy a HD4000 - de a GMA4500?" visszakérdezek, és mihez nem elég egy atom proci egy irodában?
ja és akkor elkezdesz sorolni olyan dolgokat amik az irodák 99%-ban nincs, vagy olyan marhasággal támasztod alá hogy i7 bizony kell, mint az elcseszett ekceltáblában tárolt adatbázis.
Bár natívban régóta nem programozom, de egy komplex c# vagy java programot seperc alatt összerak egy brazos is, főleg mert inkább a HDD sebessége a szűk keresztmetszet ennél is. -
-
lenox
veterán
válasz
julius666
#73
üzenetére
nem ideális a feladatra (legalábbis jelenleg) a GPU-k architektúrája.
Szerintem nem azert, hanem mert sok idobe kerul jol megirni, igy valaki megirt valamilyet valamikor (pl. a rovi vagy mainconcept meg szerintem mindig az eredeti nv altal irt cudas kodot hasznalja), de ehhez kepest cpu kodban sokkal-sokkal tobb munka van belerakva, raadasul jelenleg egysegnyi ido alatt kb. 5-szor annyi cpus kodot lehet fejleszteni.
-
julius666
addikt
válasz
atti_2010
#31
üzenetére
persze ilyenkor ha az ember ki meri ejteni hogy nincs már értelme a CPU-t erőltetni akkor egyből osztályellenség.
Nem osztályellenség, csak nem ért hozzá.
Persze el lehet itt pacsizgatni egymás közt hogy hogy a GPU-s enkódolás ennyi-meg annyi FPS-el több és ezért AMD RuL3z, max nem lesz igazatok. A GPU-s enkóderek kiváló játékszerek amíg arról van szó, laptopról valami videót amit összedobtál átkonvertálj és felhányj youtubera lehetőleg minél kisebb fogyasztás mellett minél gyorsabban anélkül, hogy gondolkozni kéne, de komolyabb feladatokra közelebb állnak a nevetséges szinthez. Egész egyszerűen ratyi az a minőség amit képesek produkálni. És nem azért mert lusták voltak a programozók hanem mert nem ideális a feladatra (legalábbis jelenleg) a GPU-k architektúrája.
Elsősorban a videokódolásról beszélek, a rendereléshez kevésbé értek, illetve ott talán több igazság van abban amit mondasz, még ha ott sem ilyen egyszerű a képlet.
Ezt párszor már leírtam itt de nincs kétségem afelől továbbra is ezt az ortó marhaságot fogjátok szajkózni. Ha nem hiszed olvass utána. Lehetőleg ne ilyen PH-jellegű oldalakon, hanem ahol tényleg értenek is hozzá.
-
MaUser
addikt
Üzemeltetsz egy külön adatbázis szervert egy 10-20mb-os Excel file helyett az iratraktárhoz vagy hogy gondoltad? De simán lehet, hogy az összes cég hülye mert azon modulokat amiket nem SAP (vagy egyéb vállalatirányítási rendszer) keretében kezelnek és megoldhatóak egy 10-20mb-os Excel file-lal meg 10-20 scriptből, ahhoz nem lőnek fel egy xxSQL szervert meg valami thin client guit.
Szerk: Irodában mihez nem elég - nem hogy a HD4000 - de a GMA4500? Komolyan érdekelne.
Ott nem játszol, nem video-t kódolsz, hanem dolgozol. Programozáshoz kell? Excell bűvölséhez? Könyvelő progihoz? Word-höz? Komolyan érdekel, mihez kell szerinted.... -
-
MaUser
addikt
válasz
atti_2010
#58
üzenetére
Ajánlom bármely versenyszféra beli munkahely megtekintését.
Notit nem áramfogyasztás miatt vesznek, érdekes is lenne ha ez az évi pár ezer forint számítana, amikor egy mérnökórád messze többe kerül, mint a gép éves fogyasztása. A notit azért veszik, mert:
- ha kell munkatárs hóna alá tudja csapni, hogy átvigye a tárgyalóba
- ha kell a melós haza/külföldre tudja vinni
- ha bedöglik könnyű cserélni, mert garantáltan ugyanaz van benne
- könnyen tudsz raktározni, és rendelésnél sincs gond x. ezer darabnál sem
- kevésebb helyet foglal (nézz rá egy irodabérlet árra és meglátod miért számít) -
atti_2010
nagyúr
Nem sok irodát láttam eddig notival felszerelve és mikor megkérdeztem hogy miért nem úgy csökkentik a villanyszámlát akkor azt mondta a főnök hogy drágább és a szervizelés is többe kerül, lehet hogy menő helyeken de ez nem általános, de hagyjuk inkább megyek olvasgatom a Kaveri híreket
![;]](//cdn.rios.hu/dl/s/v1.gif)
. -
MaUser
addikt
válasz
atti_2010
#46
üzenetére
Ezt ne erőltesd.
Egyrészt irodákban ma már szinte csak noti van (kisebb TCO miatt), azok közül meg sem i3, sem i5 nem négy magos. Nyilván a nagyobb cpu meg nem Gizikének kell a wow-hoz, hanem mondjuk a céges alkalmazásokhoz, ahol az adatbázis egy/több Excel tábla, a felület meg egy másik Excel tábla. Nem véletlenül optimalizált több magra 2007 óta az Excel egyedüli Office progiként.
Esetleg láttál már komolyabb programot ami több ezer file-ból áll? Egy ilyennek a fordítási utána reparse-olása sem két perc. Esetleg titkosított dokumentum küldése? Próbáltál egy 10-30mb-os mail-t titkosítani komolyabb programmal? Esetleg kezeltél már SAP klienst, hogy lásd mennyit számít az erősebb gép alatta?
-
atti_2010
nagyúr
profik még mindig cpu-n renderelnek, egy apróság miatt: gpu-n még nem lehet megvalósítani elég sok feature-t, amire szükségük lenne...
Pedig meg fog kelleni tanuljanak mert hamarosan az Intel sem fog sokat foglalkozni szimpla CPU-kal.
Profik, megint egy kis réteghez lyukadtunk ki akinek a kedvéért még a nagy kék testvér sem fog pazarolni.
-
yarsley
aktív tag
Direkt olyan kartyakat valasztottam, amik altalanosan ismertek es elterjedtek voltak. Geforce 1-2-om nekem is volt, 3at atugrova a 4-esbolegy ti 4200-ot vettem... Akik regebb otta kockulnak azoknak ezek konkret termekek, amit hasznaltunk. A tied elegge specialis cucc, ami nem az atlagfelhasznalonak szantak...
Amugy a 2000-es kartyan a DVI kicsit meglepett.
-
-
MaUser
addikt
válasz
atti_2010
#10
üzenetére
Ja, ahogy Móricka elképzeli. Egy teljesen átlagos irodai környezetben (ahová a legtöbb x86-ot eladják) CPU kell (most ne beszéljünk speciális területekről, oda úgyis dVGA megy). Egy nagyobb pdf megnyitása, Excel/Word macro-k futtatása, átlag e-mail kódoló progi, stb. CPU-t kér és baromira érezhető ilyen esetekben már az is ha egy i3-at i5-re cserélsz. Egy átlag programozónak meg a világ CPU-ja sem elég.
IGP irodai környezetben nagyjából tökmindegy kategória és még az is marad 5 évig. Ha lesz Excel/SAP/stb. IGP gyorsítás, majd lesz értelme. De egy parser akkor sem azon fog futni...
foxxmotor: Ja, ezt én sem értem. A T400/T500-akban benne lévő GMA4500 is bőven elég a felsorolt dolgokhoz.
-
M@trixfan
addikt
válasz
djculture
#40
üzenetére
Sajnos ez az ami borzasztó, nem konzisztens a minőség. Az Intel Quick Sync rögzített funciójú hardvert alkalmaz, ezt kivehetjük a sorból. Én csak azt nem értem, hogy az összes többi szabadon programozható VGA-ra miért nem képesek megfelelő precizitású matematikai algoritmust kódolni?
foxxmotor:
Gyakorlatilag konzol szinten lehet már játszani is vele. Ha lenne hibátlan 23.976 akkor nagyon jó HTPC-ket lehetne csinálni. Itt nem a HD3000-es hibájára gondolok, hanem úgy általában az összes GPU-ra. Sajnos sehol sincs tökéletes 23.976. Engem az lepett meg, hogy fogyasztásban nem annyira fényesek az erősebb AMD APU-k egy i5-höz képest. -
foxxmotor
tag
Teljesen egyetértek. A HD 4000-es IGP se gyenge már. HD tartalmak lejátszásához, netezéshez, mindennapi használathoz tökéletesen elég.
Úgy veszem észre, hogy pár fórumozó nincs tisztába azzal, hogy mire is való a HD 4000. A felhasználók többségének bőven elég. Akinek meg kicsi ez a teljesítmény az ne vegyen ilyet.
Végülis senkinek nincs megtiltva, hogy nVidia titan-t használjon. -
djculture
félisten
Intel ügybe is csak annyi hogy sb i7-el cpu-n media espresso nállam egy full hd anyagot 100fps-el tömörített a hd graphics-al meg 230-al. Amd vga-n sokkal gyengébben muzsikált viszont a minőség láthatóan sokkal jobb volt.Gyorsabb mozgásokat tartalmazó anyag blokkosodik ha intel graphics-on végezzük a tömörítést. Nagyyon nehéz amúgy ilyen tesztet csinálni mert mindegyik program másféle képminőségre képes különbőző gpu-n hiába ugyanazt a beállítást alkalmazzuk. Media espresso nvidián szörnyű minőségre képes amd-n viszont nagyon jóra, az intel a kettő között van de a gyors mozgást tartalmazó anyagokban hibázik.
-
válasz
atti_2010
#31
üzenetére
Senki sem vitatja, hogy nem lenne jó minél több dolgot a GPU-ra bízni, de sajnos jelenleg az a helyzet, hogy messze nincs elég ilyen progi.
Vagyis nem az APU/IGP/GPU-val van a problémánk, hanem azzal, hogy jelenleg sok olyan terület van, ahol nem használják ki a bennük rejlő erőt.
Ez nem intel<->AMD, vagy CPU<->GPU kérdés, hanem tisztán szoftver kérdés. Máshogy megfogalmazva jelen<->jövő kérdés. -
lenox
veterán
válasz
djculture
#26
üzenetére
En nem igy tudom, de lehet, hogy akkor megint utana kellene nezzek, legalabbis a legjobb minoseg es sebesseg mindig a x264-gyel szokott lenni h264-be, bar lehet, hogy akkor mar azota van jo gpu implementacio is, de utoljara mikor neztem azok eleg rosszak voltak, a 20-szoros sebesseg meg nem tudom, mikor volt, az en proggym pl. full hd-ba 60 fps felett enkodol, ettol mi lehet 20-szor gyorsabb? Tudsz valami aktualis linket? De amugy ha nem h264-be kell veletlenul, hanem dnxhd-be vagy proresbe, openexr-ba, dpx-be, stb., akkor gondolom nem jo semmire a gpu. Vagy pl. ha a forras valami specialis, hogy at kell kodolni.
-
-
djculture
félisten
-
djculture
félisten
Videó átkódolások már most is 20 szor gyorsabban történnek a gpu-n és jobb minőséget is csinálnak mint cpu-val. Lásd a totalcode studio programot ami mondjuk csak az amd és nvidia gpu-kon tud tömőríteni. De a media converter és a dvdfab már az intel grafikus magját is tudja hasznosítani.
-
tomesto
aktív tag
Szerintem Ati úgy érti, hogy nagyon-nagyon kicsike az a réteg akinek ténylegesen számít minden másodperc ilyen feladatokban, nyilván aki tud erre áldozni sok sok 10ezer pluszt annak a túloldalon ez visszajön mert neki az idő nagy pénz.
Sokan pedig tényleg nem használják ki, illetve ha kihasználja akkor otthoni felhasználásra nem biztos, hogy megéri belefeccőlni + x másodpercért sok pénzt.
Ez idő alatt inkább párhuzamosan csinál valami hasznosat -
-
-
-
atti_2010
nagyúr
de el tudnék viselni egy 20%-os CPU ugrást is.
Nem sok értelme lenne, már most sem lehet kihasználni őket csak epenisz növelésre jók, ha 3 évig nem fejlesztenének semmit a CPU-n akkor sem történne katasztrófa, a szoftveresek viszont legalább 5 éves lemaradásban vannak, hiába csücsül a bika CPU a gépben ha csak 40% van kihasználva.
-
Meglátjuk, mire lesz képes a Richland-del szemben.
No offense, még csak nem is feltétlenül tudatos sumákolásról beszélek, egész egyszerűen ahhoz, hogy legalább nagyjából objektív tesztet végezzen az ember, eléggé érteni kell hozzá és itt nem csak a PH-s részéről beszélek, hanem magáról a videós világról is. Ez nem olyasmi hogy megnyomod a 'run' gombot a bencsmárkban és kiköp egy számot. A laikusok által végzett tesztek inkább csak e-pénisznek, meg reklámanyagokba parasztvakításnak jók sajnos.
A Sandy-be meg talán a még 32 nm miatt nem került bele, talán akkor túl nagy lett volna a fogyasztás...
![;]](http://cdn.rios.hu/dl/s/v1.gif)
.
Új hozzászólás Aktív témák
Hirdetés
- The Legend of Zelda - Megvan a film két főszereplője
- Luck Dragon: Asszociációs játék. :)
- Motoros topic
- Nintendo Switch 2
- CASIO órák kedvelők topicja!
- Motorola G86 - majdnem Edge
- Abarth, Alfa Romeo, Fiat, Lancia topik
- Kertészet, mezőgazdaság topik
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- A nagy Szóda, Szódakészítés topic - legyen egy kis fröccs is! :-)
- További aktív témák...
- Olcsó Laptop! Dell Latitude 7280. I5 7300U / 8GB DDR4 / 256GB SSD
- Részletfizetés , Acer Nitro V 15 minimálisan használt uj állapot sok garancia
- ÁRGARANCIA!Épített KomPhone Ryzen 7 5700X3D 32/64GB RAM RX 7800 XT 16GB GAMER PC termékbeszámítással
- Csere-Beszámítás! Gamer PC Számítógép! R9 3900X / RX 6700XT / 32GB DDR4 / 1TB SSD
- ÁRGARANCIA! Épített KomPhone i5 14400F 32/64GB RAM RTX 5060Ti 8GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest