Új hozzászólás Aktív témák

• #14177 Fiery veterán dezz #14173

  Új Válasz 2014-05-16 18:00:11 #14177

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Fiery

  veterán

  válasz dezz #14173 üzenetére

  "Ez így azért eléggé leszűkített látómező."

  Teny, de a fejlesztoket hidd el, hogy az erdekli elsosorban, hogy mikepp tudod megoldani a feladatot, es a hibakeresest, teljesitmeny optimalizaciot hogyan tudod vegezni. Az OpenCL pedig jelenleg nagyjabol pont ezen a 2 teruleten kalap sz*r. A HSA az igeri, hogy majd jobb lesz ezeken a teruleteken is, csak epp nem latni egyelore, hogy milyen konkret lepeseket fognak tenni. Egy C++-hoz es CPU-hoz (leginkabb x86 CPU-hoz) szokott fejleszto szamara az OpenCL jelenleg egy fekete lyuk, amibe belevagod a vegrehajtando feladatot, es aztan a vegen valami kijon. Hihetetlenul nincs sem ralatasod, sem rahatasod arra, hogy mikepp hajtja vegre a GPU az adott OpenCL kernelt, es hogy a vegeredmeny valojaban helyes-e vagy sem. Ha van otleted, hogy mitol lehetne gyorsabb a cucc, akkor elkezdesz probalgatni kulonfele technikakat (pl. unroll, inline, ilyesmi), amire aztan a kulonfele GPU architekturak a kulonfele compilerekkel teljesen maskepp reagalnak. Ami fekszik az egyiknek (pl. GCN), az a masikat lassitja (pl. Kepler). Az pedig kesz rohej, amikor kenytelen vagy tobbfele GPU architekturat tobbfele driver verzioval is tesztelni, mert az egyebkent helyes OpenCL kod hibas eredmenyt ad az egyik kombinacion (pl. AMD VLIW + Catalyst 14.x). Aminek az okara, gyokerere megint nincs se ralatasod, se rahatasod, kenytelen vagy az AMD-t molesztalni, hogy javitsak vegre a rohadt driveruket. Amit persze 5 honapon belul nem tudnak megoldani, es kidobjak WHQL minosites alatt a bugos OpenCL compilert. Ez a jovo? Tenyleg?

  "Még jó, hogy ezt próbálják nyomni, ez a legfőbb ütőkártyájuk."

  Nyilvan, de ha az AMD-nek meg ott a szuper GCN -- mert hardveres szempontbol tenyleg qrvajo --, akkor miert nem azt nyomjak, hanem minden egyebet, amiben nem eleg jok? x86, ARM, szoftver fejlesztes (= HSA es tarsaikhoz valo szoftver stack).

  "Ez vicces, inkább talán az ARM szorongatja őket alulról (úgy is mondhatnám, a töküket)."

  Nezz vissza az elso Atomig. Akkor hol allt az Intel az ARM konkurensekkel szemben, es hol all most. Eg es fold a kulonbseg. Az elso iPhone megjelenesekor me'g fel sem merulhetett, hogy Intel SoC keruljon egy mobiltelefonba. Az elso iPad megjelenesekor szinten szoba sem johetett volna egy Intel SoC az ARM helyett. Mostanra pedig mar lenyegeben azonos teljesitmenyt es fogyaszast tudsz elerni Intel es ARM SoC-okkal is. Ha ezt kicsit tovabbgondolod (vagyis hogy 7 ev alatt mennyit fejlodott ebben a szegmensben az Intel), akkor eleg egyertelmu, hogy ki kinek a tökét szorongatja kozeljovoben. Mar csak azert is, mert az ARM nem egy egyseges, vertikalisan integralt CPU-gyarto, hanem egy rendkivul toredezett "valami", sokfele architekturaval, sokfele ceggel, akik raadasul sok esetben egymas konkurensei vagy epp ellensegei. Az ARMv8 remekul probalja osszefogni, gatyaba razni, modernizalni az ARM vonalat, rendkivul erdekes lesz a kovetkezo 2-3 ev...

Új hozzászólás Aktív témák