Hirdetés
-
Az Apple megszerezné a klubvilágbajnokság közvetítési jogait
ph A vállalat ezért irgalmatlan pénzt fizetne a FIFA-nak, és ezzel rajzolná át az online streaming platformok háborújában a frontvonalakat.
-
Spyra: akkus, nagynyomású, automata vízipuska
lo Type-C port, egy töltéssel 2200 lövés, több, mint 2 kg-os súly, automata víz felszívás... Start the epic! :)
-
Ilyen lesz a SteamWorld Heist II
gp A folytatás a tervek szerint a nyár folyamán, pontosabban augusztus elején érkezik.
Új hozzászólás Aktív témák
-
dezz
nagyúr
Most te tényleg az AMD-t szídod, amiért egy tőle független fejlesztő nem teszi közszemlére a kommersz szoftvere tesztváltozatának forráskódját?
(#14): Itt meg tényleg olyasmitől "félted" őket, ami a te feltételezésed (hogy az eredeti fejlesztő helyett dolgoztak)?
Benne van a cikkben, hogy később Intelre és Nvidiára is valószínűleg el fog készülni.
-
dezz
nagyúr
Értsd meg, hogy a Strongene HEVC dekódere egy zárt forrású, kommersz program. Attól, hogy OpenCL maga nyílt szabvány, még nincs előírva, hogy minden OpenCL kódnak nyílt forrásúnak kell lennie.
És légy szíves, ne állítsd be úgy, mintha az OpenCL valami olyan mágia lenne, amit csak az AMD szakemberei művelnek, más fejlesztők meg hozzá sem szagolnak. Itt a Ph!-n is többen vannak, akik ebben (is) programoznak.
A WinZIP programozói amatőrök, ez látszik a WinZIP-en is (kevésbé hatékony és jóval lassabb, mint a versenytársai és még bumfordibb is az egész program). Nem csoda, hogy az AMD csinálta meg helyettük az OpenCL kódot. Ebből nem lehet túl messzemenő következtetéseket levonni.
Tudsz mondani rá példát (az olyan tesztprogramokon kívül, mint az Everest és az AIDA), hogy más binárist adnak inteles AVX-hez, mint AMD-shez? Én nem tudok ilyenről. Azt viszont el tudom képzelni, hogy a különféle gyártók GPU-n némileg eltérő OpenCL kód fut a legjobban.
Az is benne van a pakliban, sőt talán ez a legvalószínűbb, hogy az AMD támogatta a fejlesztést, ezért cserébe átmenetileg csak AMD vason fut a GPGPU-s változat.
[ Szerkesztve ]
-
dezz
nagyúr
Egyelőre nem tudhatjuk biztosan, hogy (szintén egyelőre) miért csak AMD-n fut a GPGPU-s változat. Te azt feltételezed, hogy azért, mert az AMD szállította az OpenCL-ből fordított binárisokat. Ez következetlenség a részedről, hiszen korábban sokat írtál arról, hogy sokszor ugyanaz a kód itt vagy ott hibásan fut. Azt sem zárnám ki, hogy némileg eltérő OpenCL kód kedvez az egyik vagy a másik GPU architektúrának. És itt van még az a lehetőség is, hogy az AMD anyagilag támogatta a céget a GPGPU-s változat elkészítése érdekében, amiért cserébe átmenetileg az csak az AMD-n fut.
Az összes programozó közül ugyanúgy nagyon kevesen vannak, akik SSEx/AVX kódot készítenek és az összes program közül is nagyon kevés használja. Mégsem mondható, hogy lényegében bukás az SSEx/AVX, mert akadnak, akik használják és van egy sor jelentős program, ami használja. Az OpenCL-lel hasonló a helyzet, vannak, akik használják és már van egy sor program, ami ennek segítségével bírja munkára a GPU-t.
Nem számít, hogy feltételes módot használtál, mert általánosságban kérdeztem.
"A Strongene-nel ez a lehetoseg nem adott."
Megint feltételezésekre alapulóan teszel tényállításokat. Simán lehet, hogy nem vagy nem jól (lassan vagy hibásan) futott más gyártók GPU-in, ezért azokat egyelőre hanyagolták. Főleg, ha AMD finanszírozással készült.
A végén anyagi támogatásról beszéltem, de sikerült teljesen máshogy értelmezned.
-
dezz
nagyúr
Akkor máris két okát is láthatjuk, miért nem az OpenCL kódot adják, hanem a binárisokat:
1. Nem open-source fejlesztés.
2. Az OpenCL fordítók hibáinak kikerülése.Nem vágnak el semmit, hiszen az újabb verziókban szállíthatnak binárisokat újabb/egyéb GPU generációkhoz/architektúrákhoz is.
OpenCL kernel = OpenCL forráskód, nem? Mert akkor lásd fenti 1. pont!
Ti sem OpenCL forráskódot adtok, hanem binárist. Akkor higgyem azt, hogy nektek is a cégek készítik el a GPGPU-s részeket? Egyébként ti külön binárist adtok a különféle GPU-khoz?
BTW, éppen erre a problémára nyújt megoldást a HSA: a HSAIL bytecode nem forráskód, miközben többféle GPU-ra továbbfordítható.
Nincsenek leejtve az Nvidia és Intel felhasználók sem, csak ha egyszer az AMD finanszírozza a GPGPU-s változatot, akkor joggal kér cserébe némi előnyt a támogatásban.
"A lassan futas pedig nem jo erv, hiszen me'g egy lassu GPU is gyorsabban dekodolja a HEVC-t, mint egy mainstream x86 CPU."
Azért érv, mert ha lassabban futna pl. Nvidián, mint elvárható lenne, azzal kitették volna magukat az Nvidia és/vagy Nvidia fanok támadásának, hogy ez biztos szándékos húzás, ami etikátlanabb, mint későbbre halasztani a támogatást.
Korábban kérdezted, miért terjed olyan lassan az OpenCL alkalmazása? Nos, talán mert az Intel egyelőre inkább az SSE/AVX-es fejlesztést támogatja. Ezzel is valamilyen módon versenyeznie kell az AMD-nek.
-
dezz
nagyúr
Az Intel korábbi ténykedésének (fordítós trükközés) következményeként volt olyan, hogy egyes szoftverek csak Intelen használták ki az SSEx-t, miközben ott volt már az AMD procikban is. Nem vettem észre, hogy annak idején regényeket írtál volna az ezen való felháborodásodban.
Olyan is volt, hogy az Intel fontos distributed computing projektet pénzelt azzal a feltétellel, hogy még akkor is kizárólag CPU-n fusson, amikor már több hasonló jó ideje GPGPU-ban utazott. És máig van olyan, tesztelésre is használt jelentős szoftver (Maxon Cinema/CineBench), ami kimondottan Intelre optimalizált.A hozzáértésnek több szintje van. Sosem állítottam be úgy, mintha OpenCL-ben programoznék. (Ez később még változhat.) De azt hiszem, az átlag fórumozónál azért többet tudok róla. Szerintem erről a forráskód-titkosítási lehetőségről sokan nem hallottak még, akik napi szinten beszélnek az OpenCL-ről.
Az általad korábban elmondottak alapján ez a futás idejű fordítás eléggé nyögvenyelős dolog, minden OpenCL driver verzióval tesztelni kell minden GPU típust, stb. Nem minden fejlesztőnek van erre ideje.
"De a binaris kodokat is vissza lehet fejteni, csak az kicsivel nagyobb melo."
Sokkal nagyobb meló.
"nem csak az AMD APU-s PC-den, de maradjunk most az x86-os PC-knel, ez a jelen rogvalosag."
Nem egészen, mert ott van pl. a PS4 is. Sok megoldás ott fog először megjelenni és utána hozzák át PC-re. Pl. fizikai szimulációs megoldások és egyéb olyan számítások, amit nem csak játékprogramokban lehet felhasználni.
Nem tudom, miért állítod szembe egymással a HSA-t és az OpenCL-t. A HSA nem egy programnyelv, hanem egy architektúra, amire többféle nyelven lehet majd programozni, ezek közül az egyik az OpenCL.
Intel+Nvidia tulajként miért várod el, hogy kiszolgáljon az AMD? Az AMD GPU-k támogatása (a standard CPU-s támogatáson felül) egy plusz, amiért az AMD fizetett. Inkább az Nvidiánál és az Inelnél kellene reklamálni, hogy ők miért nem támogatják az ilyen irányú fejlesztéseket...
"Mi koze a kettonek egymashoz?"
Az, hogy ha az Intel az SSE/AVX támogatást támogatja (
), netalántán a kimondottan Intel CPU-ra való optimalizálást, akkor nem fog egy cég ingyen nekiállni az OpenCL-es támogatásnak.Elég sok CUDA-s program van, csak ezek nagy része nem hétköznapi felhasználóknak szánt PC-s szoftverekbe kerül. OpenCL támogatású programból is van már egy sor.
"rengeteg C/Delphi/Java/VB/.NET fejleszto megprobalkozott a GPGPU temaval, csak feladtak, meg tul neheznek, tul korulmenyesnek, tul elrugaszkodottnak talaltak"
Nem baj, ők majd megvárják, amíg ezekben is lehet programozni HSA-ra. Lásd pl. Java 9, Project Sumatra.
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
Igen. A Strongene előre fordított binárisokat használ. De az aktuális kód amúgy sem működne az összes hardveren. Azokra másik kód készül. Egyébként azok is binárisok lesznek.
Tudtommal OpenCL-re még az Ittiam és a Telestream is így szállít programot. Azt nem tudom, hogy ők mennyire vannak készen a munkával. Az Ittiam már bemutatta az ARM-os megoldását, míg a Telestream még csak zárt környezetben mutatta be a Switch lejátszót, de az első körben biztosan csak Kaveri APU-n fog futni.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A Strongene nem marad ennél a modellnél. Ők már a pekingi APU konferencián elmondták, hogy a jelenlegi megoldásukat leváltja majd egy szabványos HSA alternatíva, ami mindenkinek a hardverén képes futni. Az Ittiam és a Telestream is mondta korábban, hogy hosszútávon a HSA-ban gondolkodnak, így az OpenCL, előre fordított binárisokkal csak egy átmeneti megoldás.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
Olyan is volt, hogy az Intel fontos distributed computing projektet pénzelt azzal a feltétellel, hogy még akkor is kizárólag CPU-n fusson, amikor már több hasonló jó ideje GPGPU-ban utazott. És máig van olyan, tesztelésre is használt jelentős szoftver (Maxon Cinema/CineBench), ami kimondottan Intelre optimalizált.
), netalántán a kimondottan Intel CPU-ra való optimalizálást, akkor nem fog egy cég ingyen nekiállni az OpenCL-es támogatásnak.
Új hozzászólás Aktív témák
ph A 2.0-s fejlesztés az alapcsomagot, illetve egy OpenCL-es opciót is kínál.
- EDIFIER R1700BTS hangfal pár makulátlan, új állapotban, 2 év hivatalos garanciával, alkalmi áron
- LG OLED55B23LA 2 Év GYÁRI GARANCIA
- Apple iPhone XR 128GB, Kártyafüggetlen, 1 Év Garanciával
- Gamer PC , i7 12700KF , RTX 3080 Ti , 64GB DDR5 , 960GB NVME , 1TB HDD
- Intel PC , i5 8500 , 1660 6GB , 32GB DDR4 , 512GB NVME , 500GB HDD
- D-Link DIR-842 kétsávos, Gigabites router - Foxpost az árban!
- H96 MAX RK3318 TV okosító - 2/16 GB - Új!
- MacBook Pro 13" 2016, i5 2.0GHz, 8GB Ram, 256GB SSD - rossz saját képernyővel, occón!
- Logitech G502 X vezetékes gaming egér, fehér, akár 25600 DPI
- Garett GRC Maxx okosóra, fekete, Android és iOs kompatibilis
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen