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

• #134 Abu85 HÁZIGAZDA gbors #132

  Új Válasz 2015-03-05 10:55:01 #134

  Ú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

  

  Abu85

  HÁZIGAZDA

  válasz gbors #132 üzenetére

  Ez itt mindig annak a kérdése, hogy megéri-e. Az Intel berendezkedése a mai PC-s játékpiachoz nem jó. Az erre szánt pénzt 90%-ban kutatásra költik, ami igazából hasznos, csak semmit sem segít az Intel IGP-k eladásában. A maradék 10%-ból pedig nem lehet igazán jól támogatni a top stúdiókat, meg még mellette drivereket is fejleszteni. Marketingtámogatásuk nincs is. Senki sem tudja, hogy Intel-only effekt van az új GRID-ekben, stb. Alig reklámozzák ezeket a játékokat, ami a CodeMastersnek sem jó.
  Igazából csak annyi a kérdés, hogy megéri-e a büdzsét 50%-kal megemelni, ami elég komoly dollárszázmilliós tétel lenne éves szinten. Ha megemelik, akkor nyernek-e annyit, hogy ez visszajön. Minden bizonnyal a válasz nem, és így inkább leépítettek.

• #127 Abu85 HÁZIGAZDA kisfurko #126

  Új Válasz 2015-03-04 22:04:50 #127

  Ú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

  

  Abu85

  HÁZIGAZDA

  válasz kisfurko #126 üzenetére

  Másrészt pedig az Intelt már nem érdekli a hardcore gaming. Volt egy időszak, amikor erőlködtek, még komoly szakembereket is szerződtettek, de ráhagyták. Az indie-re álltak rá. A szakemberek pedig visszamentek az AMD-hez, NV-hez.

• #83 Abu85 HÁZIGAZDA julius666 #81

  Új Válasz 2015-03-03 21:08:07 #83

  Ú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

  

  Abu85

  HÁZIGAZDA

  válasz julius666 #81 üzenetére

  Mert érdemes megérteni, hogy mi változik a Vulkanban. Amúgy sem én döntöttem úgy a Khronosnál, hogy nagyon nagy százalékban lemásolják az AMD API-ját. Jól tették, de ha megtették, akkor tény lesz, hogy ez nem az ő találmányuk. Csak másoltak, mert szerencséjük volt. Persze ehhez kellett az is, hogy az AMD felajánlotta nekik a teljes forráskódot, illetve az, hogy éljenek is a lehetőséggel. Más esetben 2017-ben jött volna ez cikk az új API-ról, már ha az MS és az Apple nem tarolta volna le totálisan a piacot a DX12-vel vagy a Metallal addigra.

  Az opcionális funkciók az igazi kincsek a Vulkanban és a DX12-ben is.

• #80 Abu85 HÁZIGAZDA Jack@l #79

  Új Válasz 2015-03-03 20:48:44 #80

  Ú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

  

  Abu85

  HÁZIGAZDA

  válasz Jack@l #79 üzenetére

  A SPIR az egy egységes reprezentációs szint. Olyasmi, mint a Direct3D bájtkód.
  Igazából a bekötési modellhez semmi köze. Az arra szolgál, hogy az API besorolja a hardvereket egy előre definiált bekötési tábla alapján. Például bizonyos hardverek nem tudnak bekötni ötnél több leírótáblát, míg vannak olyanok, amelyek akármennyit betudnak kötni. Ezt muszáj kezelni az API szintjén, hogy a program futtatása ne álljon le a hatodik leírótáblát bekötésénél, ezért eleve ne is töltse be azt, és a hozzá tartozó feladatokat ne futtassa. Ez nagyon régóta így van. Ha egy funkciót egy hardver nem támogat, akkor a hozzá tartozó effekt nem engedélyezhető, különben a program kilépne egy hibaüzivel az asztalra.

• #75 Abu85 HÁZIGAZDA julius666 #74

  Új Válasz 2015-03-03 19:57:46 #75

  Ú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

  

  Abu85

  HÁZIGAZDA

  válasz julius666 #74 üzenetére

  A második bekezdésben van megemlítve, hogy a Vulkan név egy köszönetnyilvánítást jelent az AMD felé. Nélkülük ez az API most nem lenne itt. Ez nem tisztelet, mert az AMD-nek is egy üzlet ez.

  A SPIR-V-vel a mi cikkünk is elég sokat foglalkozik. Egy API-nál pedig a bekötési modell az egyik legfontosabb tényező. Amiről phoronixes cikk nem ír. Emellett az aszinkron compute és DMA is nagyon fontos. Például ilyen a DX12-ben is lesz, szóval nem árt kiemelni, hogy a Vulkanban is elérhetők. Nem mindegy ugye, hogy a GPU kihasználása 40-50 vagy 80-90 százalék. Az Oxide a hét további részében be fogja mutatni, hogy miért nem.

  A cikk címében szándékosan nincs benne az OpenCL. Azt hittem ebből sejthető lesz, hogy nem lesz a tartalmában sem. Egy külön hír van az OpenCL 2.1-ről.

• #67 Abu85 HÁZIGAZDA smkb #65

  Új Válasz 2015-03-03 17:48:10 #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

  

  Abu85

  HÁZIGAZDA

  válasz smkb #65 üzenetére

  Khronos Group elnökének ebbe nincs beleszólása, mert erről ő speciel személyesen, teljhatalmúlag nem dönt. Minden érintettnek joga van megszavazni és ellene szavazni, de olyan nincs, hogy az elnök azt mondja, hogy nem, mert csak. Ugyanakkor nem teljesen értem a hátrányt. A DX12 és a Vulkan API is tartalmaz olyan opcionális funkciókat, amelyeket az NV nem támogat egyetlen mai hardverrel sem. De egy szóval sem mondták, hogy 2016-ban nem jön jobb hardver, ami már támogatni fogja ezeket. Szóval itt ezzel senkinek semmi problémája. Évek óta létezik a kiterjesztések jelensége, és mindenki tudja, hogy a hardverek fejlődnek. A lényeg, hogy amit nem képes mindenki támogatni az legyen opcionális kiterjesztés. Ez így lesz a Vulkanban és a DX12-ben is.

• #62 Abu85 HÁZIGAZDA Valdez #61

  Új Válasz 2015-03-03 17:22:54 #62

  Ú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

  

  Abu85

  HÁZIGAZDA

  válasz Valdez #61 üzenetére

  A funkcionális analfabéták a világ oktatási rendszerének a problémái. Ezzel mindenki küzd. Nyilván az is a probléma része, hogy a médiában is elhelyezkedhet olyan ember, aki ezzel a gonddal küzd. De ne keverjük össze ezeket a dolgokat.

• #55 Abu85 HÁZIGAZDA smkb #54

  Új Válasz 2015-03-03 16:27:52 #55

  Ú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

  

  Abu85

  HÁZIGAZDA

  válasz smkb #54 üzenetére

  A cikk is írja, hogy a HLSL ment, mert az ILC csak AMD-re tud optimálisan mappelni. Ehelyett jött a SPIR-V, ami az OpenCL-ben már működik.
  Emellett írja a cikk is, hogy a bekötési modellnél ki lett dolgozva egy korlátozott rendszer, ami mellett az eredeti bekötési modell és számos funkció opcionális lett. Ezeket program oldalán lehet támogatni, ha olyan effektet fejlesztenek a stúdiók, amelyek igénylik, de ezek nélkül is futtatható lesz a program. Ugyanaz, mint a DX12-nél. Különböző funkciók különböző szintekhez vannak kötve.

• #51 Abu85 HÁZIGAZDA bbandi #49

  Új Válasz 2015-03-03 15:33:30 #51

  Ú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

  

  Abu85

  HÁZIGAZDA

  válasz bbandi #49 üzenetére

  Nem. Vagy low-level valami, vagy olyan mid-level képződmény, mint az OpenGL. Átfedésre semmi lehetőség úgy, hogy az egyik API specifikációi már évek óta léteznek. De ez nem gond. Aki teljesítményt akar Vulkant használ, aki nem akar új motort írni használhatja tovább az OpenGL-t és az OpenGL ES-t.

• #47 Abu85 HÁZIGAZDA alevan #35

  Új Válasz 2015-03-03 15:25:22 #47

  Ú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

  

  Abu85

  HÁZIGAZDA

  válasz alevan #35 üzenetére

  Egyelőre Windows 7, 8, 8.1 és majd 10, illetve friss Linux disztribúciókban működik. De az Androidba is beépíthető, csak ez még nem volt téma.

• #45 Abu85 HÁZIGAZDA bbandi #6

  Új Válasz 2015-03-03 15:20:35 #45

  Ú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

  

  Abu85

  HÁZIGAZDA

  válasz bbandi #6 üzenetére

  Maga a Mantle 1.0 a Vulkan. Ezért nincs értelme tovább futtatni a Mantle 1.0-t. Amelyik program erre készül azt még befejezik (kibaszás lenne a fejlesztőkkel, ha nem engednék meg), de aki most akarja támogatni, annak már azt mondják, hogy inkább a Vulkant támogassa, vagy a DX12-t ha a Microsofthoz akarja láncolni magát.

  Az OpenGL és az OpenGL ES nyilván megmarad, mert nem low-level API-k. Ezek a Vulkan mellett függetlenül fejlődnek. Attól, hogy vannak low-level API-k a hagyományos modellre az igény megmarad.

  A Mantle mint termék megmarad, de az 1.0-s verzió eltűnik, mert arra ott a Vulkan. Jön egy új verzió, ami a fejlesztőpartnerek extrém kívánságara lesz kihegyezve.

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