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

• #74 PandaMonium őstag SirCsimbók #73

  Új Válasz 2014-05-17 01:03:07 #74

  Ú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

  

  PandaMonium

  őstag

  válasz SirCsimbók #73 üzenetére

  OpenCL közel áll az Nvidia-hoz? Láttál te már Nvidia vs. AMD OpenCL teszteket? Egy HD7850 jobban teljesít OpenCL-ben mint egy GTX680.

• #70 PandaMonium őstag Bici #68

  Új Válasz 2014-05-15 11:59:37 #70

  Ú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

  

  PandaMonium

  őstag

  válasz Bici #68 üzenetére

  Így már érthető, köszi!

• #67 PandaMonium őstag Bici #64

  Új Válasz 2014-05-15 00:18:18 #67

  Ú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

  

  PandaMonium

  őstag

  válasz Bici #64 üzenetére

  Igen, ezekkel tisztában vagyok, csak az a gond, hogy pl. AMD driverekből már most is van nyílt forráskódú és közelében sem jár stabilitásban és teljesítményben a hivatalos zárt drivernek. Legalább is ez volt a helyzet mikor legutóbb linuxal foglalkoztam egy AMD HD7870 XT-n, azóta persze lehet, hogy változtak a dolgok.

• #58 PandaMonium őstag Abu85 #56

  Új Válasz 2014-05-14 12:29:01 #58

  Ú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

  

  PandaMonium

  őstag

  válasz Abu85 #56 üzenetére

  Ez a maffia történet nekem nagyon irreális (még ha van is mögötte logika), Abu.
  Tudsz mondani olyan példákat amiben az NV eltérne az OpenGL specifikációtól? Nem kötekedésből kérdezem, hanem egyszerűen azért mert nekem szöges ellentéte ennek a saját tapasztalatom. Rendszeresen járok StackOverflow-ra is OpenGL-es ügyekben és a problémák jelentős százaléka kb. az, hogy AMD-n valami nem megy úgy ahogy kellene a szabvány szerint (persze ez általában nem szándékos, hanem bug a driverben). Kíváncsiságból most gyorsan rákerestem az OpenGL tagnál az "AMD" kulcsszóra, 4 találat amit gyorsan elcsíptem: Link1, Link2, Link3, Link4
  Mind a 4 esetben az AMD drivereivel van a gond, van ahol a shadert nem képes a driver rendesen linkelni, van ahol a parancsok sorrendjétől függően crashel az alkalmazás, meg van ahol nem annyira toleráns mint a többi gyártó drivere (ez persze nem feltétlenül hiba).

  Linuxosokat nem értem olyan szempontból, hogy miért gond ha a driver zárt?
  Szerintem fontosabb, hogy stabil legyen a driver mintsem, hogy lehessen benne matatni.

  Őszintén szólva már az is nagy előre lépés volna ha egységes shader compiler/linker volna mint a D3D-nél, nem pedig vendoronként különböző.

• #34 PandaMonium őstag Bici #29

  Új Válasz 2014-05-14 00:03:54 #34

  Ú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

  

  PandaMonium

  őstag

  válasz Bici #29 üzenetére

  Haha, ezen jót röhögtem, köszi.

  Egyetértek a cikkel (bár igazából csak átfutottam rajta, holnap alaposabban átolvasom), túl fragmentált az OpenGL jelen pillanatban (mondom ezt úgy, hogy naponta fejlesztek vele), nagyon sokan ragaszkodnak a legacy cuccokhoz ami egyértelműen visszatartja a fejlődést, már rég megmondták, manapság már a state machine dolog nem a legjobb megoldás, gyenge dokumentáció (legalább is ami a 3.1+t illeti, legacy tutorialokból annyi van mint a fene), kevés debugolási lehetőség (már a glGetError() -on túl ), ami van az is pedig elég vicc szinten van a Direct3D megfelelőkkel szemben. AMD-ékről rég tudjuk, hogy nem tudnak OGL drivert írni, az Intelt már meg sem említem, azt viszont furcsálom, hogy állítólag az NVidia sok helyen eltérne az OpenGL specifikációtól, nekem nem ez a tapasztalatom.

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