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

• #76 con_di_B tag HussarF #59

  Új Válasz 2014-05-21 19:30:58 #76

  Ú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

  

  con_di_B

  tag

  válasz HussarF #59 üzenetére

  Na jo, azert ha CUDA-ban jol tudtal programozni, akkor nagyot neznek ha az OpenCL nem menne mint a karikacsapas.

  Gondolom kesz dolgokat is boven hasznaltal, ebben az OpenCL gyengebb ugyan, de FFT es baratai vannak ugyanugy.

• #20 con_di_B tag Abu85 #19

  Új Válasz 2014-05-20 18:13:00 #20

  Ú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

  

  con_di_B

  tag

  válasz Abu85 #19 üzenetére

  Az OpenGL-es reszrol nem tudok nyilaktozni, de az OpenCL-es resznek az az egyetlen nyilvanvalo oka van, amiert senki nem mer ra fejleszteni, hogy egy "hontalan" API-rol van szo, semelyik platformon sem idealis a tamogatottsaga. Politikailag meg az OS X a legjobb, de az meg muszakilag olyan amilyen.

  Gyanitom tortenetileg az OpenGL-nel is jatszhatott eleg erosen ez a tenyezo, hogy Windowson mindig a D3D a "kiralyi" ut.

  Olvastam persze en is a kommenteket a GL kapcsan a toolok hianyarol stb. de a valosagban ezek mind csak tunetek. Ha valamilyen oknal fogva aktivan hasznalnak, par ev alatt kinone a lemaradast, a toolok kovetik az igenyeket.

  Lam, ahol az OpenGL ES a kiralyi ut (iOS, Android), ott valamiert viszonylag ritkan megy a hiszti, h mennyire kene mar egy zart API helyette. Volt ra kiserlet (RenderScript Graphics), eleg gyorsan meg is bukott halistennek.

• #14 con_di_B tag

  Új Válasz 2014-05-20 17:37:29 #14

  Ú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

  

  con_di_B

  tag

  Lehet, hogy most nem teljesen lesz igazam, de ha jol ertem megint jopar eve megoldott dolgokon megy a ragodas. Megint csak ugyanazt tudom mondani, OpenCL 1.0 ota siman megoldhato, hogy egyszerre szamolj es mukodjon a DMA motor, raadasul mindez elegansan absztrahalva ket kulon parancssorra lebontva. (Es ami a hab a tortan, hogy meg mukodik is, AMD-n, NV-n is.)

  Ez volt az a resz, amiben biztos vagyok, de akkor persze lehet mondani, hogy ez nem grafika. Teny, de OpenGL-ben meg megregebb ota lehet aszinkron masolasi parancsokat kiadni, ami persze csunya, mert utana nem tudsz fuggosegeket definialni normalisan, de a driver oldalon ez csak annyit nehezit ugyanazon az utemezesi probleman, amit egyebkent meg kell oldania, h a fuggosegeket is o talalja ki. Ez azonban annyira nem nehez, mert altalaban ha rajzolas kozben eppen olvasnal egy texturabol, amit meg fel sem toltottel, akkor valoszinuleg ott erdemes lesz pihenni egy kicsit...

  (Vagy double bufferelsz, vagy addig van egy thumbnail, vagy amit akarsz, ami homalyos elottem, h h ertesit a rendszer arrol, hogy kesz van a masolas, de gondolom OpenGL-ben is van valami callback erre, OpenCL-ben meg szamtalan modszer van ra.)

  Szoval, megint csak azt tudom mondani, akik szerint meg kell varni az uj API-kat ahhoz, hogy normalis programokat lehessen irni, azok nem tudom mit csinaltak az utobbi evekben.

  (Ja, de, otvarabbnal otvarabb implementaciok hibait kerulgettek kenyszerbol, bocsi, nem szoltam.)

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