4. OpenGL wird dieses Jahr komplett durch Vulkan ersetzt

OpenGL wird dieses Jahr komplett durch Vulkan ersetzt

  • ?

    http://www.heise.de/newsticker/meldung/3D-API-Vulkan-von-Khronos-Eierlegende-Wollmilchschnittstelle-fuer-alle-Systeme-2565777.html

    Wird ja auch Zeit, dass OpenGL komplett in die Tonne kommt. Vulkan bietet eine API für alle Plattformen inkl. der Mobilen. Ferner gibt eine einheitliche gemeinsame Shadersprache für alle Karten und Plattformen.

    0
  • S

    Frage, ist glNext == Vulkan?

    0
  • ?

    Singender Holzkübel schrieb:

    Frage, ist glNext == Vulkan?

    Ja.

    0
  • S

    elch0 schrieb:

    Singender Holzkübel schrieb:

    Frage, ist glNext == Vulkan?

    Ja.

    Nice, danke!

    0
  • ?

    Das liest sich fast schon zu schön um wahr zu sein..
    Ist auch überfällig, dass dieses API-Chaos mal aufgeräumt wird.
    Kann mir jemand sagen wie es mit Unterstützung alter Hardware aussieht, oder alter OSs (z.B. XP - wird ja in Ausnahmen noch bis 2019 unterstützt)?
    Ach und soll es mich überhaupt stören, dass Microsoft da (noch) nicht mitmacht, denn meine Graka ist ja von Nvidia..

    0
  • ?

    AMD zieht auch voll mit und beerdigt Mantle:
    http://www.heise.de/newsticker/meldung/AMD-beerdigt-3D-Schnittstelle-Mantle-1-0-und-empfiehlt-DirectX-12-und-Vulkan-2566057.html

    Somit bliebt DirectX für Windows oder Vulkan für wirklich alles.

    0
  • M

    ByeOpenGL schrieb:

    Somit bliebt DirectX für Windows oder Vulkan für wirklich alles.

    Nicht ganz. iOS, PS 4 und wie sie alle heissen, haben noch ihre eigenen APIs.

    0
  • K

    Wo bleiben die Docs? 😕

    0
  • S

    GLNext gefällt mir als Name zwar bedeutend besser aber ich freu mich schon drauf. ^^

    0

  • Na bin schon gespannt wie DX12 und Vulkan so performen. Was MS so über DX12 erzählt klingt ja sehr vielversprechend.

    0
  • F

    hustbaer schrieb:

    Na bin schon gespannt wie DX12 und Vulkan so performen. Was MS so über DX12 erzählt klingt ja sehr vielversprechend.

    Ziemlich genau der gleiche Performancezuwachs wie mit Mantle.Hier ein Vergleich mit der Star Swarm Demo. Wobei DirectX12 noch beta-Status hat. Glaub allerdings nicht das sich da noch viel an Performance verändert, ist ja schon so schnell wie Mantle.

    EDIT: so wirklich vielversprechend find ich das nicht, auch nur das was Mantle macht.

    Kellerautomat schrieb:

    Wo bleiben die Docs? 😕

    Zu Vulkan findet nur https://www.khronos.org/assets/uploads/developers/library/overview/2015_vulkan_v1_Overview.pdf. Und da liest man nur was von CommandBuffern wie man sie aus DirectX 11 kennt. Absolut revolutionär...
    Ah und SPIR-V womit man seine Shader schon von vornherein kompilieren kann, was man von DirectX 9 (korrigiert mich falls ich falsch lieg, aber ich meine das war von Anfang an dabei) her kennt. Ist ja noch viel revolutionärer 😉
    Ah und eine API auf allen Geräten (PC, Handy) was so auch schon von DirectX 11 kennt (ok jetzt hör ich auf 😃 ) und (was so noch nicht kannte) Autos, 3D-Drucker (wtf??) Drohnen (noch mehr wtf, Hä? was soll das andere Beispiel hätten nun wirklich besser gepasst), etc...

    Ok fairerweise sollte man wohl dazu sagen, dass Vulkan auch nicht wirklich revolutionär sein soll, sondern einfach nur Overhead reduzieren soll. Und das wird es wohl hinkriegen.

    Naja, alles in allem ist das alles irgendwie längst überflüssig. Nur den Namen hätten sie nun wirklich nicht ändern müssen.

    floorball

    0

  • Ach watt, (EDIT: der Name) OGL Next ist doch doof, Vulkan ist viel kuhler 🙂

    0
  • R
    Mod

    floorball schrieb:

    hustbaer schrieb:

    Na bin schon gespannt wie DX12 und Vulkan so performen. Was MS so über DX12 erzählt klingt ja sehr vielversprechend.

    Ziemlich genau der gleiche Performancezuwachs wie mit Mantle.Hier ein Vergleich mit der Star Swarm Demo. Wobei DirectX12 noch beta-Status hat. Glaub allerdings nicht das sich da noch viel an Performance verändert, ist ja schon so schnell wie Mantle.

    wobei StarSwarm sehr unoptimiert rendern wie hier zu lesen ist und mit den normalen optimierungen vermutlich auf beiden platformen noch schneller waere.

    Kellerautomat schrieb:

    Wo bleiben die Docs? 😕

    Zu Vulkan findet nur https://www.khronos.org/assets/uploads/developers/library/overview/2015_vulkan_v1_Overview.pdf. Und da liest man nur was von CommandBuffern wie man sie aus DirectX 11 kennt. Absolut revolutionär...

    auch DX12 optimiert auf diese weise, ich denke das indiziert dass da doch ein unterschied sein muss 😉

    Ah und SPIR-V womit man seine Shader schon von vornherein kompilieren kann, was man von DirectX 9 (korrigiert mich falls ich falsch lieg, aber ich meine das war von Anfang an dabei) her kennt. Ist ja noch viel revolutionärer 😉

    wobei SPIR-V als intermediate language dient, das bedeutet, dass der schwerpunkt auf flexibilitaet und ausdrucksstaerke liegt. das directX binary ist auf der anderen seite schon stark optimierter opcode und die driver muessen manchmal viel magic machen um rauszufinden was gemacht wird und es geht manchmal schief. Es ist eher wie PTX von nvidia wuerde ich sagen.

    Ah und eine API auf allen Geräten (PC, Handy) was so auch schon von DirectX 11 kennt (ok jetzt hör ich auf 😃 ) und (was so noch nicht kannte) Autos, 3D-Drucker (wtf??) Drohnen (noch mehr wtf, Hä? was soll das andere Beispiel hätten nun wirklich besser gepasst), etc...

    gibt es von opengl ja auch schon ewig. wenn der driver das supportet kannst du auch auf dem handy opengl4.4 nutzen (z.B. auf den shield devices von nvidia).
    ist glaube was die sagen wollen ist dass es einheitlicher wird. ich glaube du kannst bei DX11 auf handy z.b. nicht tesselation oder sowas nutzen.

    Ok fairerweise sollte man wohl dazu sagen, dass Vulkan auch nicht wirklich revolutionär sein soll, sondern einfach nur Overhead reduzieren soll. Und das wird es wohl hinkriegen.

    wobei das meiste nur CPU beschleunigen soll. auf PCs (gerade mit intel CPU) bringt das nicht viel da die meisten spiele GPU bound sind, einfach deswegen weil, wenn du noch performance uebrig hast, drehen die leute aufloesung, filterung, antialiasing, features auf bis es eben GPU limitiert ist. und wenn du am GPU limit bist, wird es kaum etwas bringen Mantle/Vulkan/DX12 zu nutzen... z.B. http://www.anandtech.com/show/8998/directx-12-star-swarm-intel-igpu-performance-preview

    Naja, alles in allem ist das alles irgendwie längst überflüssig. Nur den Namen hätten sie nun wirklich nicht ändern müssen.

    finde ich nicht. ich finde den NVidia ansatz mit ein paar nuetzlichen extensions besser. damit bekommst du die ganze moegliche performance und mit minimalem investment.

    0
  • F

    rapso schrieb:

    auch DX12 optimiert auf diese weise, ich denke das indiziert dass da doch ein unterschied sein muss 😉

    Aus Sicht des Programmierers auf jeden Fall schon mal nicht 😃 .
    Auch ansonsten dürfte meiner Meinung nach kaum ein Unterschied sein, na gut in Zukunft werden wohl auch Intel und AMD Command Lists Treiberseitig unterstützen aber das macht NVidia ja auch schon länger.
    DX12 unterteilt außerdem nochmal zwischen Command Lists und Bundels damit die Treiber wissen was sie cachen sollten und was nicht.

    rapso schrieb:

    finde ich nicht. ich finde den NVidia ansatz mit ein paar nuetzlichen extensions besser. damit bekommst du die ganze moegliche performance und mit minimalem investment.

    Ich glaube OpenGL fährt in Zukunft auch zweigleisig, d.h. Es wird wohl OpenGL 5 und Vulkan geben und bei DX wird es wohl DX11.3 und DX12 geben. So gesehen ist nichts verloren.

    floorball

    0
  • M

    rapso schrieb:

    Naja, alles in allem ist das alles irgendwie längst überflüssig. Nur den Namen hätten sie nun wirklich nicht ändern müssen.

    finde ich nicht. ich finde den NVidia ansatz mit ein paar nuetzlichen extensions besser. damit bekommst du die ganze moegliche performance und mit minimalem investment.

    Das Problem ist, dass OpenGL 20 Jahre ballast mit sich rumschleppt. Von frueher hat man noch solche Funktionen, um die translation und rotation einzeln zu setzen und Punkte einzeln zu rendern.
    Heutzutage wuerde man so eine API gar nicht mehr bereitstellen, sondern maximal noch fertige Matrix setzen, index- und vertexlist rendern, wenn man nicht gleich das buffer vertex object rendert.
    Frueher hatte man noch einzelne features, wie alpha-blending, die man einzeln aktivieren konnte. Heutzutage sind Grafikkarten frei programmierbar. Vulkan arbeitet statt mit einzelner Textur- und Objektdaten direkt auf dem Speicher der Graka.
    Dieser ganze Kram ist zum einen fuerchterlich unuebersichtlich zum lernen und zum anderen ist es sehr schwer, ausreichend vollstaendige Implementierungen zur Verfuegung zu stellen. Es gibt auch in den offiziellen Implementierungen der Grafikkartenfirmen viele Features, die kaum getestet sind und Mesa haengt noch bei OpenGL 3.3.

    Wenn man ein modernes Programm mit OpenGL schreibt, muss man erstmal jede Menge Extensions aktivieren und aufpassen, dass man die herstellerspezifischen optional macht.

    rapso schrieb:

    Ah und eine API auf allen Geräten (PC, Handy) was so auch schon von DirectX 11 kennt (ok jetzt hör ich auf 😃 ) und (was so noch nicht kannte) Autos, 3D-Drucker (wtf??) Drohnen (noch mehr wtf, Hä? was soll das andere Beispiel hätten nun wirklich besser gepasst), etc...

    gibt es von opengl ja auch schon ewig. wenn der driver das supportet kannst du auch auf dem handy opengl4.4 nutzen (z.B. auf den shield devices von nvidia).
    ist glaube was die sagen wollen ist dass es einheitlicher wird. ich glaube du kannst bei DX11 auf handy z.b. nicht tesselation oder sowas nutzen.

    Ich denke, mit dem einheitlichen meinen sie, dass damit OpenGL und OpenGL ES zusammengefasst wird und beim Design auch WebGL Anbindung mit bedacht wurde.

    0
  • R
    Mod

    floorball schrieb:

    rapso schrieb:

    auch DX12 optimiert auf diese weise, ich denke das indiziert dass da doch ein unterschied sein muss 😉

    Aus Sicht des Programmierers auf jeden Fall schon mal nicht 😃 .

    gerade aus sicht des programmierers. niemand anderes wird einen unterschied sehen 😉

    Auch ansonsten dürfte meiner Meinung nach kaum ein Unterschied sein, na gut in Zukunft werden wohl auch Intel und AMD Command Lists Treiberseitig unterstützen aber das macht NVidia ja auch schon länger.

    es hat mehr mit DX2 commandbuffern zu tun als mit DX11 😉

    DX12 unterteilt außerdem nochmal zwischen Command Lists und Bundels damit die Treiber wissen was sie cachen sollten und was nicht.

    primaerer grund von bundles ist dass treiber sie compilieren koennen. quasi sowas wie renderlist compilieren bei opengl.

    0
  • R
    Mod

    Marthog schrieb:

    Das Problem ist, dass OpenGL 20 Jahre ballast mit sich rumschleppt.

    nein, nicht wirklich, sowohl bei openGL ES wie auch opengl (ich glaube) 3.3 sind veraltete funktionen nicht mehr supportet. der balast ist also schlimmstenfalls ein paar jahre alt (vielleicht DX10 zeit).

    Von frueher hat man noch solche Funktionen, um die translation und rotation einzeln zu setzen und Punkte einzeln zu rendern.
    Heutzutage wuerde man so eine API gar nicht mehr bereitstellen, sondern maximal noch fertige Matrix setzen, index- und vertexlist rendern, wenn man nicht gleich das buffer vertex object rendert.

    das aktuelle opengl hat das nicht.
    du kannst natuerlich die alte API aufgreifen, aber du kannst wohl auch noch directX 5 initialisieren.

    Frueher hatte man noch einzelne features, wie alpha-blending, die man einzeln aktivieren konnte. Heutzutage sind Grafikkarten frei programmierbar. Vulkan arbeitet statt mit einzelner Textur- und Objektdaten direkt auf dem Speicher der Graka.

    es arbeitet weiterhin mit textur und objektdaten. auch mantle macht es so, obwohl du gewisse kontrolle ueber den speicher hast, es ist weit von dem entfernt was du z.b. in C unter "kontrolle" verstehst.

    Dieser ganze Kram ist zum einen fuerchterlich unuebersichtlich zum lernen und zum anderen ist es sehr schwer, ausreichend vollstaendige Implementierungen zur Verfuegung zu stellen.

    mit Vulkan bzw DX12 wird es fuer die hersteller einfacher. viele dinge die der treiber gemacht hat sind dann auf deiner seite. Vom eigentlichen treiber bleibt nur noch der unterste layer der wirklich nur daten ein wenig aufbereitet und zur GPU schiebt. synchronisierung, etc. liegt dann alles bei dir. zwar nicht so schoen und frei wie auf konsolen, aber dennoch weit mehr in deiner hand als opengl.

    wenn es nach mir ginge, waere es noch ein bisschen lower level. so wie es jetzt ist, ist es relativ abstrakt, sodass du eigentlich alles an kontrolle hast, aber du weisst nicht 100% was passiert, weil es relativ platformuebergreifend sein muss. es muss auf NVidia, ATI, Intel, PowerVR, Qualcom etc. laufen. unter windows, android, linux, osx. Es muss funzen wenn sich windows in hybernation legt und wenn android dir den halben speicher wegnehmen will. etc etc.

    Wenn man ein modernes Programm mit OpenGL schreibt, muss man erstmal jede Menge Extensions aktivieren und aufpassen, dass man die herstellerspezifischen optional macht.

    muss man eigentlich nicht, mit latest opengl hast du echt viele moeglichkeiten, eigentlich soviel wie mit DX11 und damit werden schliesslich die allermeisten spiele gemacht.

    rapso schrieb:

    Ah und eine API auf allen Geräten (PC, Handy) was so auch schon von DirectX 11 kennt (ok jetzt hör ich auf 😃 ) und (was so noch nicht kannte) Autos, 3D-Drucker (wtf??) Drohnen (noch mehr wtf, Hä? was soll das andere Beispiel hätten nun wirklich besser gepasst), etc...

    gibt es von opengl ja auch schon ewig. wenn der driver das supportet kannst du auch auf dem handy opengl4.4 nutzen (z.B. auf den shield devices von nvidia).
    ist glaube was die sagen wollen ist dass es einheitlicher wird. ich glaube du kannst bei DX11 auf handy z.b. nicht tesselation oder sowas nutzen.

    Ich denke, mit dem einheitlichen meinen sie, dass damit OpenGL und OpenGL ES zusammengefasst wird und beim Design auch WebGL Anbindung mit bedacht wurde.[/quote]das hoffe ich auch. feature maessig sollten die GPUs alle gleich sein. sollte keinen grund geben APIs fuer mobile extra zu machen, Vulkan soll ja vor allme CPU seitig sparen und das ist die schwachstelle von mobile bisher.

    0
  • F

    rapso schrieb:

    floorball schrieb:

    rapso schrieb:

    auch DX12 optimiert auf diese weise, ich denke das indiziert dass da doch ein unterschied sein muss 😉

    Aus Sicht des Programmierers auf jeden Fall schon mal nicht 😃 .

    gerade aus sicht des programmierers. niemand anderes wird einen unterschied sehen 😉

    DX11 Command Lists:

    ID3D11DeviceContext* d3d11DefferedContext;
d3d11Device->CreateDefferedContext(... , &d3d11DefferedContext); //Erstellen

d3d11DefferedContext->BlaBlaBla(...); // Kommandos Speichern
ID3D11CommandList* commandList;
d3d11DefferedContext->FinishCommandList(... , &pd3dCommandList); //Schließen

d3d11DeviceContext->ExecuteCommandList(commandList, ...); //Abspielen

    Wo ist der Unterschied (für den Programmierer) zu z.B. DX12 Bundels, die in etwa so aussehen werden:

    pDevice->CreateCommandList(D3D12_COMMAND_LIST_TYPE_BUNDLE, pBundleAllocator, pPSO, pDescriptorHeap, &pBundle); //Erstellen 
pBundle->BlaBlaBla(...); //Kommandos Speichern
pBundle->Close(); //Schließen
//Nichts konkretes dazu gefunden wie bundles abgespielt werden, vermutlich aber von CommandLists aus
pCommandList->ExecuteBundle(pBundle, ...); //Abspielen

    Auch ansonsten kann (und soll(te)) man DX11 Command Lists benutzen wie DX12 Bundles.
    Wieso sollte auch gerade für den Programmierer ein Unterschied zu sehen sein 😕

    rapso schrieb:

    es hat mehr mit DX2 commandbuffern zu tun als mit DX11 😉

    Und unter NVidia werden DX11 Command Lists als Command Buffer realisiert. Unter AMD und Intel nicht. Oder versteh ich hier was falsch?

    floorball

    0
  • R
    Mod

    floorball schrieb:

    Wo ist der Unterschied (für den Programmierer)

    bei dem einen rufst du den treiber auf der dann drawcalls in den von dir gewuenschten buffer hinterlegt, bei dem anderen schreibst du selbst commands in einen commandbuffer.
    bei dem einen ist es jacke wie hose ob du das in 1 oder 10 buffer fuellst, bei dem anderen kannst du die 10 commandbuffer zur gleichen zeit ausfuehren als ob du 10 devices haettest. bei dem einen hast du im commandbuffer alles an synchronisierung und daten updates eingebacken und der treiber wird das alles durchgehen und analysieren und dafuer sorgen dass es richtig ablaeuft. bei dem anderen nimmt die GPU einfach was du reinschreibst und notfalls zerlegt es deine scene, aber das ist niemandens schuld/verantwortung ausser deiner....

    Auch ansonsten kann (und soll(te)) man DX11 Command Lists benutzen wie DX12 Bundles.
    Wieso sollte auch gerade für den Programmierer ein Unterschied zu sehen sein 😕

    weil in dem einen fall jemand fuer dich kocht und du sagst nur dass du suppe, pizza, wurst etc. willst und entsprechend passiert es automatisch und du hast keine ahnung welches gift drinnen ist. bei dem anderen musst du selbst kochen.

    auch wenn es bei aussenstehenden wie "nahrungsversorgung" aussieht, sind es fuer dich koch..emm.. programmierer zwei welten.

    rapso schrieb:

    es hat mehr mit DX2 commandbuffern zu tun als mit DX11 😉

    Und unter NVidia werden DX11 Command Lists als Command Buffer realisiert. Unter AMD und Intel nicht. Oder versteh ich hier was falsch?

    keine implementierung ist wirklich gut, weil keine implementierung im voraus wissen kann was du damit eigentlich anstellen willst. dabei muss jede implementierung dir alles moegliche garantieren. was passiert wenn du 10 commandlists hast und in den 10 denselben buffer updaten willst?.... bei schnellen APIs sagt die API dir "I dont care" und deswegen ist es eine schnelle API.

    oder aus welchem grund benutzt fast niemand commandlists von DX11 aber jeder hebt sie zum heiligen gral bei DX12,Vulkan,Mantle,Consoles?

    0
  • ?

    Mal im ernst, wenn Vulkan draußen ist wen interessiert denn dann noch DirectX? Es geht doch eh weg von Microsoft, wenn auch langsam. Denkt nicht nur immer an diesen Blockbuster-Schund. Aber selbst da werden immer mehr Engines portiert.

    0
Anmelden zum Antworten