Vulkan Grafik-API

[Guest83]

http://abload.de/img/glnextvru86.jpg

Die Khronos Group arbeitet derzeit an einem neuen, offenen Grafik-API für alle Plattformen. Statt OpenGL weiter zu entwickeln, möchte man den gesamten Ballast, der sich über die letzten 22 Jahre angesammelt hat, hinter sich lassen und eine moderne Schnittstelle schaffen. Das soll die API vor allem attraktiver für Entwickler machen.


An open-standard, cross-platform 3D+compute API for the modern era
- Compatibility break with OpenGL
- Start from first principles

Goals
- Clean, modern architecture
- Multi-thread / multicore-friendly
- Greatly reduced CPU overhead
- Architecture-neutral
– full support for tile-based as well as direct renderers
- Predictable performance
- Improved reliability and consistency between implementations

Eine Übersicht zu den Zielen findet man hier: https://www.khronos.org/assets/uploads/developers/library/2014-siggraph-bof/OpenGL-Ecosystem-BOF_Aug14.pdf


Konkrete technische Details und Live-Demos mit glNext sollen auf der GDC Anfang März veröffentlicht werden. Die Präsentation wird von Engine-Entwicklern von Valve, Epic, Unity und EA (Frostbite) durchgeführt.

Join us for the unveiling of Khronos' glNext initiative, the upcoming cross-platform graphics API designed for modern programming techniques and processors. glNext will be the singular choice for developers who demand peak performance in their applications. We will present a technical breakdown of the API, advanced techniques and live demos of real-world applications running on glNext drivers and hardware.

http://schedule.gdconf.com/session/glnext-the-future-of-high-performance-graphics-presented-by-valve

[Tyrann]

hoffentlich macht glNext DirectX ordentlich Konkurrenz

[Guest83]

Naja, Direct3D ist Windows-exklusiv, von daher gibt es nur teilweise eine Konkurrenzsituation.

Die große Frage die ich mir stelle ist, wie es mit der Abwärtskompatibilität aussieht, ob es auch mit älteren Grafikkarten funktionieren wird. Denn man bricht ja bewusst mit der Vergangenheit, um den ganzen Ballast von OpenGL los zu werden. Und soweit ich weiß muss so eine API ja auch vom Treiber unterstützt werden?!

[Screemer]

Wenns die Treiber hergeben und das feature-set der GPU stimmt, dann sollte dem nichts im weg stehen. Geh aber bei amd mal von min. Gcn 1.0 aus. Ich hätte an AMDs stelle jetzt auch nicht grad Bock noch nen Treiber für alte Vliet Geschichten zu bauen.

[Langenscheiss]

Ich schätze mal schon, dass die API auch auf Grakas, die nur DX9 abwärts in Hardware haben, laufen wird. Die Ziele klingen so, als wenn am meisten an der Optimierung der CPU Auslastung getan wird. Eine grundsätzliche Inkompatibilität gäbe es ja nur, wenn die API auf ein Hardware-Level insistieren würde, aber warum will man das bei einer API, die möglichst neutral zur Plattform ist? Das meiste klingt so, als könnte man es mit einem passenden Treiber unterstützen. Die Frage ist dann allerdings nur, ob die Hersteller mitziehen und entsprechende Treiber anbieten.

[Terrarist]

Naja, Direct3D ist Windows-exklusiv, von daher gibt es nur teilweise eine Konkurrenzsituation.

Die große Frage die ich mir stelle ist, wie es mit der Abwärtskompatibilität aussieht, ob es auch mit älteren Grafikkarten funktionieren wird. Denn man bricht ja bewusst mit der Vergangenheit, um den ganzen Ballast von OpenGL los zu werden. Und soweit ich weiß muss so eine API ja auch vom Treiber unterstützt werden?!

Gut möglich dass es bei AMD erst mit dem neuen amdgpu Treiber, also ab Tonga (285x) unterstützt wird. Die meinten ja mal dass neue Features nicht mehr für den bisherigen Catalyst/fglrx implementiert werden, sondern halt nur noch für die neuen Karten, und glnext wäre ja so ein Feature.

[Eidolon]

Ich bin gespannt und schließe mich der Meinung mit der Konkurrenz an, wäre echt mal gut.

edit: Passend dazu: http://derstandard.at/2000011281863/glNext-Valve-zeigt-Zukunft-der-Spielegrafik-Anfang-Maerz

[Coda]

Ich schätze mal schon, dass die API auch auf Grakas, die nur DX9 abwärts in Hardware haben, laufen wird.
Mit Sicherheit nicht. Viel zu viele Kompromisse mit dem Binding-Modell.

Wenn sie das tun wird das wieder kein sauberes Ding.

[kruemelmonster]

Ich schätze mal schon, dass die API auch auf Grakas, die nur DX9 abwärts in Hardware haben, laufen wird.

Bitte nicht, und wozu auch? Wer jetzt immer noch eine GF 7 oder Radeon X hat der braucht auch keine neue API.
Und nur für mein Tablet mit einem sieben Jahren alten PowerVR SGX540 will ich keine Kompromisse haben wenn dadurch meine GTX 670 auch nur um 1% benachteiligt wird.

Frei nach Victoria Nuland: Fuck the SM3!

[HarryHirsch]

ob das was wird? nach dem was man so über opengl liest blockt einer die ideen des anderen.

[Guest83]

Naja, ich finde es jedenfalls interessant, dass die Präsentation der Spezifikationen ausschließlich von Engine-Entwicklern vorgenommen wird und nicht ein einziger IHV involviert ist. Vielleicht ist das ein Zeichen dafür, dass die bei glNext mehr zu sagen haben bzw. stärker beteiligt sind als früher und man es deshalb nicht direkt mit der Entwicklung von OpenGL vergleichen kann?

[kevsti]

Aber auch die könnten sich in der Quere kommen, entweder weil sie gegenseitige Meinungen zu bestimmten Features oder Implementierungen haben oder weil schlichtweg jeder sich ein Haufen Feature "wünscht" und man nicht überein kommt, was man nun implementiert...
Das Problem ist letztlich ähnlich, zu viele Köche verderben den Brei... Ist leider in der OpenSource Welt ein weit verbreitetes Phänomen. Und nicht nur dort.
Lieber wäre es mir wenn eine einzige Firma eine neue (Multiplattform) Schnittstelle entwickeln und etablieren würde - was natürlich (zum jetzigen Zeitpunkt jedenfalls) utopisch ist.

Aber warten wirs ab, wenn sie sich von vorne herein besser organisieren und bestimmte Regelungen zum Miteinander finden und einhalten - könnte es vielleicht wirklich was werden.

[Timbaloo]

Was ist in dem Kontext unter dem Ziel "Predictable performance" genau zu verstehen?

[M4xw0lf]

Was ist in dem Kontext unter dem Ziel "Predictable performance" genau zu verstehen?
Dass für den Entwickler ersichtlich ist, warum etwas wann gut oder scheiße läuft.

[Demogod]

execution units analysing tools auf treiber ebene?

[Fusion_Power]

Dass für den Entwickler ersichtlich ist, warum etwas wann gut oder scheiße läuft.
Heißt das die Devs wissen momentan oft nicht mal warum ihre eigenen Sachen scheiße laufen? :freak:

Nun, es wäre ein logischer Schritt neben den neuen Mantle, DX12 APIs auch was neues und schlankes an der Open GL Front am Start zu haben. ich vermute, gerade Valve pusht das hart wegen Steam OS, das ja auf Linux aufbaut. Hoffentlich wirds was, die letzte "spezielle" Open GL Version die angeblich super optimiert war (GLES) hat mich jedenfalls nie überzeugt. War am ende ein kastriertes OpenGL für mobile Geräte, ohne wirklich einschalgende Verbesserungen. Dagegen klingt dieses "Next" wirklich fast wie ein Neuanfang.

[Locuza]

Bei Mantle gab es das Thema Black-Box.
Der Treiber ist nicht transparent und macht vieles automatisch.
Es ist schwer vorherzusehen wie eine gewisse Szene reagieren wird, also muss man immer experimentieren, etwas raten, Sicherheitsbuffer einplanen.

Mit Manlte und DX12 ändert sich das Design, der Treiber wird dünner, viele Sachen können die Engines direkt entscheiden und müssen es auch.

[Eidolon]

Ein starkes und viel genutztes glNext/OpenGL wäre für uns (dem Kunden) das Beste.

DX12 von MS nützt letztendlich nur Microsoft und so langsam sollte auch der Letzte mitbekommen wie das bei MS mit den PC Spielern läuft. Alle paar Jahre wird hoch und heilig versprochen das PC Spieler nun im Fokus stehen, passend zur Ankündigung eines neuen Desktopsystems für das es dann exklusiv genau das DX gibt.
Und kurz danach ist das die hauseigene Konsole wieder im Mittelpunkt.

Mantle ist auch nicht gerade kundenfreundlich, denn was bringt es dem Kunden wenn dieses optimal auf AMD Karten läuft, aber nicht auf anderen Karten anderer Anbieter? Eigentlich das gleiche Spiel wie bei MS nur auf Hardwarebene.

Lieber ein offenes System was eben auf jeder Hardware und Software gut läuft, endlich mal mehr Unabhängigkeit und nicht gebunden an die Willkür einzelner Hersteller..

[gixe]

Naja, ich finde es jedenfalls interessant, dass die Präsentation der Spezifikationen ausschließlich von Engine-Entwicklern vorgenommen wird und nicht ein einziger IHV involviert ist.

Die sind wahrscheinlich damit beschäftigt ihre glNext Treiber zu verkrüppeln "zertifizieren" damit man weiter teure Workstationkarten für CAD und andere professionelle Sachen verkaufen kann. :freak:

[RLZ]

Lieber ein offenes System was eben auf jeder Hardware und Software gut läuft, endlich mal mehr Unabhängigkeit und nicht gebunden an die Willkür einzelner Hersteller..
Ohne Konkurrenz kommt es zu Stillstand und DAS ist schlecht für uns.
Alle Beteiligten haben das schon ausführlich demonstriert.

[Eidolon]

Ohne Konkurrenz kommt es zu Stillstand und DAS ist schlecht für uns.
Alle Beteiligten haben das schon ausführlich demonstriert.

Ja seit Jahrzenten, allen voran MS.

[RLZ]

Ja seit Jahrzenten, allen voran MS.
Die kannst du mit der Khronos Group in einen Sack stecken und draufkloppen.

[Coda]

Heißt das die Devs wissen momentan oft nicht mal warum ihre eigenen Sachen scheiße laufen? :freak:
Ja. Manche Sachen muss bei DX11 der Treiber machen z.B Speicherallozierung/Defragmentierung. Das ist eine Black Box.

Das gute an DX12/Mantle/glNext ist dass das so low level ist, dass so Zeug gar nicht mehr geht. Das einzig nervige ist dann noch der Shader/Pipeline-Compiler.

[del_4901]

Das einzig nervige ist dann noch der Shader/Pipeline-Compiler.Stell dich nicht so an. Pipelineobjects sind awesome!

[Guest83]

Das gute an DX12/Mantle/glNext ist dass das so low level ist, dass so Zeug gar nicht mehr geht.
Low-Level-Access ist ja jetzt das große Buzzwort für die neuen APIs, von dem alle schwärmen. Aber hat das nicht auch Nachteile im Sinne von einem gestiegenen Aufwand für die Entwickler? Also dass man Dinge, die früher automatisch von der Schnittstelle erledigt wurden, nun selbst machen muss? Damit kann man zwar bessere Ergebnisse erzielen, aber es ist halt eine zusätzliche Arbeit, die man vorher nicht hatte. So würde ich das zumindest verstehen, oder hat es wirklich nur Vorteile?

[Coda]

Stell dich nicht so an. Pipelineobjects sind awesome!
Trotzdem ist es ne Black-Box. Manchr Konsolen haben so was nich ;)

Low-Level-Access ist ja jetzt das große Buzzwort für die neuen APIs, von dem alle schwärmen. Aber hat das nicht auch Nachteile im Sinne von einem gestiegenen Aufwand für die Entwickler? Also dass man Dinge, die früher automatisch von der Schnittstelle erledigt wurden, nun selbst machen muss?
Ja, das ist so.

[Demirug]

Low-Level-Access ist ja jetzt das große Buzzwort für die neuen APIs, von dem alle schwärmen. Aber hat das nicht auch Nachteile im Sinne von einem gestiegenen Aufwand für die Entwickler? Also dass man Dinge, die früher automatisch von der Schnittstelle erledigt wurden, nun selbst machen muss? Damit kann man zwar bessere Ergebnisse erzielen, aber es ist halt eine zusätzliche Arbeit, die man vorher nicht hatte. So würde ich das zumindest verstehen, oder hat es wirklich nur Vorteile?

Es gibt ja auch Entwickler die DX 12 aus dem Grund nicht wollen. Tendenziell Allerdings eher im Bereich der Visualisierung wo man das Overhead Problem eben mit Hardware erschlägt oder hohe Frameraten nicht so wichtig sind.

Trotzdem ist es ne Black-Box. Manchr Konsolen haben so was nich ;)

Irgendwo muss man eben abstrahieren wenn man nicht riskieren will das Software mit einer neuen Hardware Generation nicht mehr läuft.

[del_4901]

Trotzdem ist es ne Black-Box. Manchr Konsolen haben so was nich ;)
Manchr Konsolen compilliert auch alles offline. Das es nicht einfach ist den ganzen State zusammen zu suchen ist klar, aber a sind dann wir dann dazu da das moeglich zu machen.

[Coda]

Irgendwo muss man eben abstrahieren wenn man nicht riskieren will das Software mit einer neuen Hardware Generation nicht mehr läuft.
Das ist mir bewusst.

[Fusion_Power]

Ja. Manche Sachen muss bei DX11 der Treiber machen z.B Speicherallozierung/Defragmentierung. Das ist eine Black Box.

Das gute an DX12/Mantle/glNext ist dass das so low level ist, dass so Zeug gar nicht mehr geht. Das einzig nervige ist dann noch der Shader/Pipeline-Compiler.
Warum hat man das nicht gleich von Anfang an so gemacht? Damalige technische Limitierungen oder einfach typische, über die Jahre "gewachsene" Software wo immer mehr dazu geschüttet wurde bis keiner mehr den Durchblick hatte?

[Terrarist]

Ohne Konkurrenz kommt es zu Stillstand und DAS ist schlecht für uns.
Alle Beteiligten haben das schon ausführlich demonstriert.

Jein, denn Zukunftstechnologien wie VR und AR sind nur durch einen Fortschritt im Softwarebereich massentauglich. Das ist einfach im Interesse der beteiligten Unternehmen dass es dort einen Fortschritt in Sachen Performance gibt. Die haben, so sollte man annehmen, kapiert dass Blockaden auf dieser low level Ebene eher jedem schaden, von daher konzentrieren sie sich wohl eher auf den Wettbewerb auf anderer Ebene.

Deshalb hat glnext auch eine rosige Zukunft, Microsoft ist der Meister darin Politik zu eigenen Gunsten zu betreiben um durch Technologiehoheit den Wettbewerb mit der Brechstange durch Exklusivität zu verzerren. Betrachtet man den Markt und das mögliche Wachstum als Ganzes, dann sind Blockaden auf dieser Ebene völlig falsch für eine blühende Wirtschaft. Man kann nur hoffen dass sich Microsoft selbst besinnt und mehr in Richtung offene Technologien unternimmt, nicht nur aus Image-Gründen. Es gibt ja schon erste Anzeichen dafür in Bereichen die marktpolitisch für sie nicht so wichtig sind.

Anderenfalls wird MS untergehen, denn es gibt mittlerweile einfach zu viele Player die die volle Kontrolle über die Technologien benötigen damit deren Vision aufgeht. Zudem tanzt MS auf sehr vielen Tech-Hochzeiten und macht vielen Firmen die vllt. vor 10 jahren ihr Business noch auf MS-Software aufgebaut hätten Konkurrenz. Und wirkliche Konkurrenz ist es dann halt nicht wenn man die OS-Technologiehoheit inne hat, eher Wettbewerbsverzerrung die eben langfristig ein Echo der potentiell dadurch gefährdeten Unternehmen erzeugt.

[Chris Lux]

Nur noch einmal zur Erinnerung:

AMD hopes to put a little Mantle in OpenGL Next (http://techreport.com/news/26922/amd-hopes-to-put-a-little-mantle-in-opengl-next)
Huddy told us AMD has done a "great deal of work" with the Khronos Group, the stewards of the OpenGL spec, on OpenGL Next. AMD has given the organization unfettered access to Mantle and told them, in so many words, "This is how we do it. If you want to take the same approach, go ahead." Khronos is free to take as many pages as it wants out of the Mantle playbook, and AMD will impose no restrictions, nor will it charge any licensing fees.

[del_4901]

ManGLe :ugly:

[Unicous]

@Chris Lux

Johan Andersson (Technical Director bei DICE bzw. jetzt EA und zuständig für die Mantle Implementierung in die Frosbite 3 Engine/BF4) und Dan Baker (u.a. Lead Graphics Programmer für DX11 und zuständig für die Mantle Implementierung in Star Swarm /Nitrous Engine) werden bei der glNext Präsentation mit dabei sein.:wink:

[Chris Lux]

Ich weiss...

[IC3M@N FX]

Wie wird sich glNext für Konsolen auswirken z.b PS4 (GNM,GNMX), Android (OpenGL ES), Apple (Metal)??? deren Spiele basieren ja mehr oder weniger auf OpenGL oder irre ich mich total????

[Terrarist]

Wie wird sich glNext für Konsolen auswirken z.b PS4 (GNM,GNMX), Android (OpenGL ES), Apple (Metal)??? deren Spiele basieren ja mehr oder weniger auf OpenGL oder irre ich mich total????

Die PS4 nutzt eigene, proprietäre Grafiklibs, da wirkt sich das vermutlich gar nicht aus, bzw. könnte mir vorstellen dass Sony höchstens ebenfalls auf glnext umsattelt falls es für sie Sinn macht, also dort Arbeitskraft gespart werden soll und sich die proprietäre Technik nicht mehr lohnt..

Ansonsten wird glnext OpenGL ES und "Desktop OpenGL" erstzen bzw. vereinheitlichen, da gibts in Zukunft dann wohl keinen Unterschied mehr zwischen Mobile und Desktop.

Im Appleversum betrifft Metal ja nur iOS, bzw. exklusiv/nativ für iOS entwickelter Content. glnext wäre dann die Wahl für fast alles was cross platform läuft. Vermutlich wird glnext jedoch Metal ähnlicher sein als DX12, da eben *nix ausgerichtet.

[RavenTS]

Wie wird sich glNext für Konsolen auswirken z.b PS4 (GNM,GNMX), Android (OpenGL ES), Apple (Metal)??? deren Spiele basieren ja mehr oder weniger auf OpenGL oder irre ich mich total????

Für die aktuellen Konsolen ist der Zug sicherlich abgefahren...

[Guest83]

Ich versteh nicht ganz, wieso die Leute bei Ankündigungen zu APIs (war bei Mantle und DX12 genauso) immer sofort auf die Konsolen schielen. Dort haben die Entwickler doch ohnehin bereits Low-Level-Access und durch die gleichbleibende Hardware eine ganz andere Entwicklungsumgebung als am PC. Also fällt mir nicht nur hier auf, auch in anderen Foren.

[Eidolon]

Verstehe ich auch nicht, eigentlich sollten die Konsolen bei so etwas erst einmal völlig egal sein. Insbesonders welche, die schon auf dem Markt sind.

[Coda]

Für die aktuellen Konsolen ist der Zug sicherlich abgefahren...
Wieso sollte der Zug was Software angeht abgefahren sein? Nicht das es sonst irgend einen Sinn ergeben würde.

Was hier wieder wirres Zeug geredet wird ist unglaublich.

[-/\-CruNcher-/\-]

Crytek ist "noch" nicht on board ?

Valve wird da wohl die ersten Realtime Demos der neuen Source Engine (Next Gen) (HL 3,L4D2 remastered) präsentieren :)

werden wohl die geleakten slides von 2011 zu tage kommen als bewegt demo ;)

http://www.valvetime.net/attachments/l4d2-1-png.24674/
http://gon.cdn.on.net/uploads/2014/01/source2.jpg

Die Art des Lighting und der Render Results errinert mich total an Ryse ;)

[Knuddelbearli]

Valve hat "Dank" steambox ja auch das größte Interesse daran

[Guest83]

Crytek ist "noch" nicht on board ?

Valve wird da wohl die ersten Realtime Demos der neuen Source Engine (Next Gen) (HL 3,L4D2 remastered) präsentieren :)
Unwahrscheinlich. Da soll ganz klar die API im Mittelpunkt stehen, nicht eine Engine-Demonstration. Am ehesten vorstellen könnte ich mir den Source 2 Port von Dota 2, weil man dann direkt die Performance mit der Source 1 Version vergleichen könnte, bei identischer Grafik. Für wahrscheinlicher halte ich aber, dass die angesprochenen Live-Demos in Unreal oder Unity zu sehen sind.


Die Art des Lighting und der Render Results errinert mich total an Ryse ;)
Das wurde mit dem Dx11-Renderer erstellt (war das einzige was erwähnt wurde, gab nicht einmal einen Verweis auf OpenGL, wenn ich mich richtig erinnere) und bei dem Screenshot stand einfach nur "Global Illumination" dabei, ohne irgendwelche näheren Details.

[N0Thing]

Wieso sollte der Zug was Software angeht abgefahren sein? Nicht das es sonst irgend einen Sinn ergeben würde.

Was hier wieder wirres Zeug geredet wird ist unglaublich.

Also bist du der Meinung, dass glNext bei der Entwicklung für die PS4 eine Option wäre?

[IC3M@N FX]

Also bist du der Meinung, dass glNext bei der Entwicklung für die PS4 eine Option wäre?

Eher ist bestimmt gemeint das der PC nicht das Bauchnabel der Welt ist und glNext nicht vom PC abhängt ob dieser Standart hält oder fällt........

Abgesehen davon warum sollte Sony in der Khronos Group sein und davon nicht profitieren? Welche Produkte hat den Sony momentan die von glNext profitieren könnten..... PS4, PS Vita, Sony Moblie Devices, Multimedia Geräte, Sony TV´s???
Ich glaube schon das sie sich das genau anschauen, vielleicht werden sogar teile davon bzw. Möglichkeiten vielleicht auf GNM übertragen oder abgeguckt/inspirieren lassen weiß der Teufel. Ich kenne mich da nicht so aus aber bestimmt hat es seine Gründe das Sony dabei ist.....

[Chris Lux]

Das Eingangsposting zeigt u.a.: Qualcomm, Samsung, ARM, Imagination... wo zur Hölle seht ihr da eine PC-only Bindung?

Da ist doch ganz klar was "glNext" sein wird. Höchstwahrscheinlich wird es kein "glNext ES" geben...

@Coda: Da Epic, Valve etc. bei der Spec-Definition dabei waren: Wurde Crytec auch zumindest angefragt?

[del_4901]

Epic und Valve zahlen aber auch, und Epic sogar richtig viel!

[Demirug]

Das Eingangsposting zeigt u.a.: Qualcomm, Samsung, ARM, Imagination... wo zur Hölle seht ihr da eine PC-only Bindung?

Da ist doch ganz klar was "glNext" sein wird. Höchstwahrscheinlich wird es kein "glNext ES" geben...

@Coda: Da Epic, Valve etc. bei der Spec-Definition dabei waren: Wurde Crytec auch zumindest angefragt?

Wenn man bei Khronos was sagen will muss man den entsprechenden Status haben.

https://www.khronos.org/members/contributors

Crytek war wohl nicht bereit die $15,000 pro Jahr zu bezahlen.

[deekey777]

Also bist du der Meinung, dass glNext bei der Entwicklung für die PS4 eine Option wäre?
Die Frage wäre nur dann von Relevanz, wenn du mit 100%-iger Sicherheit sagen kannst, dass die PS4 heute OpenGL unterstützt und glNext der nächste logische Schritt wäre.

[Chris Lux]

Wenn man bei Khronos was sagen will muss man den entsprechenden Status haben.

https://www.khronos.org/members/contributors

Crytek war wohl nicht bereit die $15,000 pro Jahr zu bezahlen.
Für "glNext" ist man aber auch offen auf die ISVs zugegangen um deren Input zu bekommen. Ich dachte das wäre eine gute Sache auch für Crytec gewesen. Ok, aber wenn es dann doch auch noch Geld kostet.... ;)

[Eidolon]

OpenGL und damit auch glNext war nie PC Only, von daher. ;)

[-/\-CruNcher-/\-]

Wenn man bei Khronos was sagen will muss man den entsprechenden Status haben.

https://www.khronos.org/members/contributors

Crytek war wohl nicht bereit die $15,000 pro Jahr zu bezahlen.

Unitys Mitgliedschaft kann man dann wohl als zur richtigen Zeit am richtigen Ort bezeichnen im Mobile Hype ;)

[Chris Lux]

OpenGL und damit auch glNext war nie PC Only, von daher. ;)
Ich bin echt gespannt wie sie Tiled-Renderer und pure Forward-Renderer unter einen Hut bringen.

[deekey777]

OpenGL und damit auch glNext war nie PC Only, von daher. ;)
Nur tristet OpenGL abseits des PCs ein Schattendasein.

[Eidolon]

Nur tristet OpenGL abseits des PCs ein Schattendasein.

Ist das wirklich so? Smartphones, Tablets, ...?

[deekey777]

Ist das wirklich so? Smartphones, Tablets, ...?

Ich habe ein Tablet mit einem Z3740. (Das ist meine Logik.)

Auf ARMen Tablets und Smartphones ist OpenGL_ES die maßgebende Schnittstelle (HL2 läuft über OpenGL, wenn ich mich nicht irre). Android beherrscht ja OpenGL, aber wird auch benutzt?

[-/\-CruNcher-/\-]

Nur tristet OpenGL abseits des PCs ein Schattendasein.

Wenn dann bitte abseits des *nix PCs ;)
aber wie gesagt Smartphone, Tablets und Co da kommt OpenGL low level gerade richtig für :)
Vor allem jetzt wo Microsoft ja auch dort agressiver hin drängt mit DX12 :)

[Coda]

Also bist du der Meinung, dass glNext bei der Entwicklung für die PS4 eine Option wäre?
Nein. Aber es ist kein Zug abgefahren.

Ich bin echt gespannt wie sie Tiled-Renderer und pure Forward-Renderer unter einen Hut bringen.
Was soll da das Problem sein? Seit Jahren benutzen wir die gleichen APIs für beide Varianten.

[deekey777]

Nein. Aber es ist kein Zug abgefahren.
Anders gesagt:
Sony kann die Unterstützung jederzeit selbst liefern, wenn sie wollen.
Oder?

Ich bin echt gespannt wie sie Tiled-Renderer und pure Forward-Renderer unter einen Hut bringen.
Wie meinst du das?
Irgendwie schaffen die Entwickler das heute.

[Guest83]

Epic und Valve zahlen aber auch, und Epic sogar richtig viel!
Wundert mich ein wenig, dass Valve nur Contributor (15.000 US-Dollar) und nicht Promoter (60.000 US-Dollar) ist, wenn man bedenkt, wie wichtig eine attraktive API, die auch auf Linux und somit SteamOS läuft, für Valve in Zukunft ist. Und sie sind ja sonst nicht scheu beim Geld ausgeben, so haben sie letztes Jahr die DebConf gesponsert und dass bei dem GDC-Talk "prestend by Valve" dabei steht, wird wohl ebenfalls heißen, dass es von Valve finanziert wird. Aber möglicherweise sind die Promoter-Plätze, mit denen ja auch mehr Rechte und Einfluss über die Spezifikationen von glNext verbunden sind, limitiert und es gab keinen freien Platz mehr.


Anders gesagt:
Sony kann die Unterstützung jederzeit selbst liefern, wenn sie wollen.
Oder?
Ich will Coda keine Worte in den Mund legen, aber ich hab sein Posting so verstanden, dass er das nur als allgemeines Statement meinte, ohne direkten Bezug auf glNext. Also dass man nicht sagen kann, dass die Softwareentwicklung für die PS4 abgeschlossen sei und Verbesserungen für diese Generation keine Relevanz mehr hätten, wie es der Vorposter angedeutet hat.

[del_4901]

Was soll da das Problem sein? Seit Jahren benutzen wir die gleichen APIs für beide Varianten.
AFAIK ist das Bindingmodel der meissten Tiler noch aus der Steinzeit. Und ein DFR muss auch wissen wann ein Pass anfaengt und zuende um seine Bandbreite richtig aussspielen zu koennen.

[Chris Lux]

Was soll da das Problem sein? Seit Jahren benutzen wir die gleichen APIs für beide Varianten.
Wir reden hier über eine extreme low-level API. Da gibt es mit Sicherheit Unterschiede bei den beiden Ansätzen. Und auch heute gibt es bestimmte Extensions für die Optimierung von Tiled-Architekturen [1]. Ich kann mir nicht vorstellen, dass das direkt zum Start wieder durch Vendor-Extensions gelöst wird und man sofort wieder das selbe OpenGL Problem hat.

[1] https://www.khronos.org/registry/gles/extensions/QCOM/QCOM_tiled_rendering.txt

[Coda]

AFAIK ist das Bindingmodel der meissten Tiler noch aus der Steinzeit.
Das ist aber ein anderes Problem.

Und ein DFR muss auch wissen wann ein Pass anfaengt und zuende um seine Bandbreite richtig aussspielen zu koennen.
Das muss der Treiber bisher auch schätzen.

Es gibt paar optionale Extensions um das expliziter zu machen, aber ich seh nich warum die ganze API dafür anders sein muss.

[del_4901]

Das muss der Treiber bisher auch schätzen.
Der Treiber soll gerade eben nichts mehr schaetzen, sondern NUR das machen was man Ihm sagt. Sonst kann man sich das low Level gedonks auch gleich spaaren.

[Coda]

Ich weiß nicht ob ein Forum für diese Diskussion wirklich das ideale Medium ist. Wir reden vermutlich wieder viel aneinander vorbei.

[robbitop]

Warum nicht? IMO ist eine Diskussion von 2 Profi-Entwicklern, die beide wissen wovon sie reden, für die Allgemeinheit immer sehr wertvoll und lehrreich. :)

[Coda]

Er ist halt aber auch immer so kurz angebunden :D

[Demogod]

so wie du?! ^^

[del_4901]

Hahaha, ertappt :)

[Coda]

Ich hab deshalb "auch" geschrieben, das war schon auf mich bezogen.

[Arcanoxer]

AMD Has A New Linux/OpenGL Driver Relationship Representative (http://www.phoronix.com/scan.php?page=news_item&px=AMD-Linux-GL-Dev-Relations)

[-/\-CruNcher-/\-]

Hehe Su setzt wohl auf neues blut der muss viel kitten ;)

http://www.g-truc.net/post-0702.html

[HarryHirsch]

glnext-vorstellung auf der gdc von valve (http://hexus.net/tech/news/software/80414-valve-present-glnext-high-performance-graphics-gdc/)

[y33H@]

Die Sessions sind schon seit Wochen online, ergo keine Neuigkeit?

[Demogod]

wie wird sich das auf die cross-platform treiberentwicklung auswirken? durch reboot >90% codesharing? (osx/unix allgemein/linux/windows)

[Coda]

Versteh ich nicht, der OpenGL-Treiber von NVIDIA ist auf Linux jetzt schon praktisch der selbe wie auf Windows.

[sth]

wie wird sich das auf die cross-platform treiberentwicklung auswirken? durch reboot >90% codesharing? (osx/unix allgemein/linux/windows)
Hoffentlich.

Versteh ich nicht, der OpenGL-Treiber von NVIDIA ist auf Linux jetzt schon praktisch der selbe wie auf Windows.
Ja, aber nVidia sind die einzigen, die das bisher hinbekommen haben (dementsprechend sind nVidias Linux-Treiber auch die einzigen, die nicht komplett Grütze sind).

[Locuza]

The Khronos Group filed a trademark request earlier this month with the USPTO over the name Vulkan as it pertains to drawing 2D/3D graphics... Vulkan might be the name of the next-generation OpenGL specification due to be announced next week.
http://www.phoronix.com/scan.php?page=news_item&px=Khronos-Group-Vulkan-API

Wäre ein netter Name wie ich finde.

[-/\-CruNcher-/\-]

http://de.wikipedia.org/wiki/Kronos

Anführer der Titanen und Vater von Zeus.


http://de.wikipedia.org/wiki/Vulcanus

eine Berufung war es, neben Geschmeide oder Bronzetore, auch die Wunderwaffen für die Götter und Halbgötter zu schmieden

[Coda]

Ja, aber nVidia sind die einzigen, die das bisher hinbekommen haben (dementsprechend sind nVidias Linux-Treiber auch die einzigen, die nicht komplett Grütze sind).
"Ja, aber" tut hier nichts zur Sache. Es gibt auch beim "alten" GL keinen technischen Grund den Code nicht zu teilen.

[sth]

Es gibt auch beim "alten" GL keinen technischen Grund den Code nicht zu teilen.
Technische nicht, aber historische.

Beispiel: ATIs Windows-Treiber haben ihren Ursprung in Ontario, die Linux-Treiber in Starnberg. Das waren komplett getrennte Projekte, die von komplett getrennten Teams entwickelt wurden. Zwar hat ATI/AMD das Team in Starnberg schon vor einigen Jahren aufgelöst und die Linux-Entwicklung auch nach Kanada geholt (mit dem Ziel größeren Code-Sharings zwischen beiden Treibern), aber den Vorsprung von nVidia (die es ja schon seit den Anfängen so machen) haben sie trotzdem noch nicht einholen können.

Man kann nur hoffen, dass die IHVs diese einmalige Chance nutzen und mit glNext (wie auch immer es heißen wird) gleich den richtigen Pfad einschlagen werden. Das es technisch sinnvoll ist wird allen klar sein, aber es ist eben auch eine personelle und strukturelle Frage. Sowas ist in der Praxis nicht selten das größte Problem.

[Coda]

Technische nicht, aber historische.
Seine Frage war ob das neue GL (oder wie es auch immer heißt) irgendwelche Vorteile bringt. Ich sage nein.

[Lord_X]

Die Schnittstelle soll wohl "Vulkan" heissen:

http://tsdr.uspto.gov/#caseNumber=86539994&caseType=SERIAL_NO&searchType=statusSearch

[d2kx]

http://www.phoronix.net/image.php?id=0x2015&image=vulkan_api_coming

As a follow-up to last week's "Vulkan" trademark by the Khronos Group and mulling it over this weekend, I've now been able to confirm with two independent entities that Vulkan is indeed the next-gen graphics API designed as the successor to OpenGL for high performance 2D/3D graphics.

The Vulkan details will go public on 3 March tomorrow for GDC2015. For whatever silly reason I wasn't pre-briefed on the matter even though Phoronix is the leading source for Linux OpenGL/graphics information, etc, there were two sources that came through and delivered official documents on Vulkan and the forthcoming OpenCL 2.1. While I'm not under NDA with Khronos, I respect the work done by them and their stakeholders, so as such I won't spill all the beans ahead of time. Just to say today that Vulkan is indeed the name for their new open API for high-efficiency access to modern GPUs across all platforms from desktops to mobiles to embedded/consoles. While Vulkan delivers highly-efficient graphics/compute, OpenGL and OpenGL ES will continue to evolve.

The key Vulkan details are pretty much what one could have assumed now for months given all the talk generated by Direct3D 12, Mantle, Metal, etc. There's also one other exciting nugget: SPIR-V. There will also be open-source Vulkan tools coming.

More details tomorrow.

Source: http://www.phoronix.com/scan.php?page=news_item&px=Khronos-Vulkan-Graphics-API

[Guest83]

For whatever silly reason I wasn't pre-briefed on the matter even though Phoronix is the leading source for Linux OpenGL/graphics information, etc
Lol.

[Unicous]

Larabel hat zwar einerseits recht, dass er die Haupt-Informationsseite ist, aber das ist auch vor allem dem unwahrscheinlichen Gespamme geschuldet, das er fast jeden Tag veranstaltet. Zu jedem Furz eine News und dann auch noch nicht einmal tiefgründig. Seine "Reviews" sind auch ein schlechter Witz und Openbenchmarking auch nicht wirklich ernstzunehmen. Dafür ist die Seite mit Werbung zugepflastert, was dazu führt, dass die Seite mit oder ohne Adblocker unbenutzbar ist.


Den Namen finde ich übrigens nicht sehr gelungen, ich dachte ehrlich gesagt sie nutzen glNext oder so ähnlich. Hätte mir persönlich gefallen. Vulkan ist einfach nur nichtssagend. Die API ist kein Videospiel oder Konsumprodukt das einen fancy Namen braucht. Aber gut, das ist nebensächlich, Hauptsache wir bekommen endlich mal eine performante Cross-Plattform-API to rule them all. (Die Hoffnung stirbt zuletzt)

[Terrarist]

Vulkan passt doch perfekt zum (Earth) Mantle! :D

[aufkrawall]

Ne Gefälligkeit an AMD, dafür, dass sie sich so am SC bedienen konnten?

/Spekulatius

[Unicous]

Vulkan passt doch perfekt zum (Earth) Mantle! :D

Daran hatte ich auch schon gedacht.:wink:
Es wurde auch schon von mehreren Stellen behauptet, dass glNext sehr, sehr viel Gemeinsamkeiten mit Mantle hat (carbon copy) und ich könnte mir auch vorstellen, dass Mantle in OGL "überführt" wird und man so auch den Linux-Support sicherstellen kann, während man Mantle als CUDA Alternative aufbaut um im professionellen Markt aufzutrumpfen.

Aber dennoch müssten sie mir mal den Namen erklären. Bis jetzt finde ich ihn einfach nur lame. Wenn sie es wenigstens "Vulcan" wie bei ST genannt hätten, oder Spock's Beard.:tongue:

[Terrarist]

https://www.khronos.org/vulkan

https://www.khronos.org/assets/uploads/developers/library/overview/2015_vulkan_v1_Overview.pdf

https://www.khronos.org/registry/spir-v/papers/WhitePaper.pdf

[Ganon]

Liest sich schon mal nicht schlecht. Das man jetzt endlich eine Zwischensprache hat und somit nicht jeder Treiber auf Source-Ebene arbeiten muss, ist schon ein Vorteil. Liest sich quasi wie das Gallium3D-Konzept in Mesa3D gekreuzt mit Mantle. Offenbar nimmt man sich auch das Tooling zu Herzen. Ein offizieller Shader-Compiler wäre schon was. Nicht mehr Bugsuche pro Treiber. *träum*

Mal hoffen, dass das auch nicht alles gleich wieder einschläft und die Hersteller es unterstützen (nicht so wie NVidia <-> OpenCL 2.0).

Man sollte jetzt ja quasi "ein x86 für die GPUs" geschaffen haben, wenn man das so richtig deuten kann? Würde zumindest meine Ansicht von letztens etwas ändern.

[Terrarist]

Man sollte jetzt ja quasi "ein x86 für die GPUs" geschaffen haben, wenn man das so richtig deuten kann?

Joa, nur besser da es nicht auf wenige/einen Hersteller limitiert ist. Für Physx und Cuda gibt es bald wegen spir-v auch keine wirkliche Daseinsberechtigung mehr wenn OpenCL jetzt besser und einfacherer zugänglich ist. Beides, also Vulkan und OpenCL in einer leicht zugänglichen API vereint ist schon eine Revolution.

[Ganon]

Joa, nur besser da es nicht auf wenige/einen Hersteller limitiert ist. Für Physx und Cuda gibt es bald wegen spir-v auch keine wirkliche Daseinsberechtigung mehr wenn OpenCL jetzt besser und einfacherer zugänglich ist. Beides, also Vulkan und OpenCL in einer leicht zugänglichen API vereint ist schon eine Revolution.

Das ist der Punkt den ich noch spannend erwarte... Khronos selbst wird wohl keine Tools (außer vllt. einen offiziellen Shader-Compiler) ausspucken. Das machen dann andere Firmen, nur das diese nun Treiber/Herstellerunabhängig funktionieren sollten.

Der Vorteil von CUDA ist einfach, dass die Tools und der Support von NVidia dort einfach besser ist. Da bringt einem halt die beste API nichts, wenn man keine Tools hat um mit diesen umzugehen.

Das ist ja wie mit Compilern für CPUs auch. Wenn du nur GCC 0.1 kriegst, dann würde ich das auch nicht tun :D Gerade so Debugger sind essentiell.

[Terrarist]

So sollte es sein, offene Plattform und darauf aubauend eben ein fairer Wettbewerb. Ist doch ideal wenn zwischen den Tool Machern Wettbewerb herrscht, davon wird jeder letztendlich profitieren.

[Unicous]

Gibt einen writeup zu Vulkan bei Anandtech, die NDA ist wohl vor einer Stunde gefallen.

http://anandtech.com/show/9038/next-generation-opengl-becomes-vulkan-additional-details-released

[Terrarist]

KdnRI0nquKc

http://blog.imgtec.com/powervr/trying-out-the-new-vulkan-graphics-api-on-powervr-gpus

[Exxtreme]

Vulkan passt doch perfekt zum (Earth) Mantle! :D
Passt auch zu Khronos/Qo'noS. ;)

[deekey777]

Passt auch zu Khronos/Qo'noS. ;)
Das frage ich mich, seit es Khronos gibt: griechische Mythologie oder Star Trek?

[Exxtreme]

Das frage ich mich, seit es Khronos gibt: griechische Mythologie oder Star Trek?
In diesem recht speziellen Falle IMHO eindeutig Star Trek. ;)

[Unicous]

Nö.

https://twitter.com/repi/status/572870761867689985

bzw.

https://twitter.com/booner_k/status/572877720264155136

[labecula]

Und somit hat nun AMD Mantle offiziell beerdigt. Sieht doch gut aus!

[Blediator16]

Und somit hat nun AMD Mantle offiziell beerdigt. Sieht doch gut aus!

Vuntle lebt weiter :biggrin:

[del_4901]

ManGLe!!!!!

[d2kx]

Source Engine 2 ist offiziell. Voller Support für Vulkan für Windows & Linux.

Valve announced the Source 2 engine, the successor to the Source engine used in Valve's games since the launch of Counter-Strike: Source and Half-Life 2. "The value of a platform like the PC is how much it increases the productivity of those who use the platform. With Source 2, our focus is increasing creator productivity. Given how important user generated content is becoming, Source 2 is designed not for just the professional developer, but enabling gamers themselves to participate in the creation and development of their favorite games," said Valve's Jay Stelly. "We will be making Source 2 available for free to content developers. This combined with recent announcements by Epic and Unity will help continue the PCs dominance as the premiere content authoring platform."
Also as part of supporting PC gaming, Valve announced that it will be releasing a Vulkan-compatible version of the Source 2 engine. Vulkan is a cross-platform, cross-vendor 3D graphics API that allows game developers to get the most out of the latest graphics hardware, and ensures hardware developers that there is a consistent, low overhead method of taking advantage of products. Vulkan, previously called Next Generation OpenGL, is administered by the Khronos Group, along with other standards such as OpenCL, OpenGL, and WebGL.


Valve is love, Valve is life.

[Nightspider]

Sehr schön. DICE wird wohl auch aufspringen und Crytek und Cloud Imperium Games sicherlich auch. Damit haben wir schon viele Größen im Boot.

Fuck the police Microsoft.

[Loeschzwerg]

Nö.

https://twitter.com/repi/status/572870761867689985

bzw.

https://twitter.com/booner_k/status/572877720264155136

https://twitter.com/nvidiadeveloper/status/572755646707318784

Live long and prosper ;D

[Spasstiger]

Aber dennoch müssten sie mir mal den Namen erklären. Bis jetzt finde ich ihn einfach nur lame. Wenn sie es wenigstens "Vulcan" wie bei ST genannt hätten, oder Spock's Beard.:tongue:
Im CB-Forum hat es einer geschrieben. Ein Vulkan öffnet den Erdmantel.

[misterh]

http://www.computerbase.de/2015-03/erste-details-zum-opengl-nachfolger-vulkan/#update1

[Unicous]

Im CB-Forum hat es einer geschrieben. Ein Vulkan öffnet den Erdmantel.

Na doof bin ich auch nicht. Darauf bin ich und andere auch schon gekommen, nur eben im Mantlethread. Und im Zweifelsfall glaube ich nicht, dass im CB-Forum die wachesten Geister unseres Landes verkehren, eher die jüngsten und pubertärsten.:wink:

[Timbaloo]

Letztlich vollkommen egal wer sie wo von was weshalb bedient hat. Das Projekt steht und fällt mit breiter Unterstützung, oder wichtiger noch indem man DX12 den Mittelfinger zeigt.

Ist ja nicht so, dass es die erste Cross-Platform Grafik-API wäre...

[Lord_X]

Kann ein Mod. den Thread hier umbenennen in Vulkan?

[Grundkurs]

hoffentlich lässt sich Vulkan ein bisschen leichter programmieren als OpenGL :-O

[Nightspider]

Kann ein Mod. den Thread hier umbenennen in Vulkan?

Wieso heißt das eigentlich nicht Vulcan? Gibts doch nur mit C im Englischen oder?

[derF]

Das was du meinst ist volcano.

[fondness]

Im englischen würde das Volcano heißen, man hat sich aber für das deutsche Wort Vulkan entschieden.

[Unicous]

Wieso heißt das eigentlich nicht Vulcan? Gibts doch nur mit C im Englischen oder?

Weil es auch Khronos heißt, anstatt Chronos. ;-)

Und weil es in vielen nordischen Sprachen nunmal Vulkan heißt. ;-)

Das ist schon ziemlich gewitzt. Die Nähe zum klingonischen bzw. vulkanischen Heimatplaneten nimmt man sicherlich gerne mit. Entwickler haben eben auch gerne mal ein bisschen Spaß bei der Namenssuche.

[Nightspider]

Weil es auch Khronos heißt, anstatt Chronos. ;-)

Ja gut das hätte für mich auch gut Feuerländisch sein können. Ich kenne nicht alle griech. Götternamen. Mein Gott heißt Tombman. :cool:

[Chris Lux]

hoffentlich lässt sich Vulkan ein bisschen leichter programmieren als OpenGL :-O
Nope... ;)

Und das ist gut so.

[hell_bird]

Kann jemand etwas zum technischen von SPIR-V kommentieren? Das scheint mir doch schonmal eine Revolution zu sein. So wie es aussieht haben sie es geschafft den kleinsten gemeinsamen Nenner für alles zu finden ohne zu viele Zugeständnisse an alte Hardware zu machen (logical addressing ist vielleicht etwas unschön). Mir fällt überhaupt kein Grund ein warum das nicht zur lingua franca für alle GPU Sachen werden sollte. Außerdem sollten hoffentlich quelloffene Bibliotheken für OpenGL, DirectX und OpenCL 2.0 (Hallo Nvidia :mad:) nur noch eine Frage der Zeit sein.

Jetzt wo alle Möglichkeiten offen sind frage ich mich in welcher Programmiersprache man am besten GPU Code zu schreibt. Kann man da überhaupt Grafik und Compute auf einen Nenner bringen? OpenCL 2.1 ist mit dem Subset von C++14 schon ziemlich attraktiv, allerdings geht es standardmäßig davon aus, dass aliasing erlaubt ist. Keine Ahnung ob das so einen großen Unterschied macht, aber SPIR hat da explizit zwei Modi.

[Gipsel]

Kann jemand etwas zum technischen von SPIR-V kommentieren? Das scheint mir doch schonmal eine Revolution zu sein.Na Revolution ist wohl etwas zu viel.
IR bzw. IL gab es ja auch schon vorher, sowohl bei DirectX, bei OpenCL als auch z.B. intern bei AMD (eng an DirectX angelehnt, aber auch unified zwischen Grafik und Compute) und auch nV (PTX ist auch nur eine Intermediate Language in dem Sinne, daß das ein Pseudoassembly ist, welches die Hardware abstrahiert und vom Treiber noch per Compiler auf die eigentliche ISA gemappt wird).

[Knuddelbearli]

Gibt es auch was zu SFR wurde das mit übernommen? Bzw die Voraussetzungen dafür.

[Kartenlehrling]

es gibt doch zu AMD LiquidVR SDK infos .

http://www.pcper.com/files/imagecache/article_max_width/review/2015-03-03/06.jpg

Affinity multi-GPU brings us to the past - a return of SFR, split frame rendering.

AMD realizes as most of us have that the ability to map a GPU to each eye makes the most sense and is surprisingly easy to integrate.
The benefit again is lower latency, rather than the inherent delay in a multi-GPU alternate frame system (AFR).
Developers will also benefit from lower CPU overhead thanks to a removal of duplicate common operations between the two eyes.
This is not limited to just two GPUs though - AMD said that 3, 4, 5 GPUs could all be supported if the developer builds in support.
http://www.pcper.com/reviews/Graphics-Cards/AMD-LiquidVR-SDK-Aims-Silky-Smooth-VR-all-Headsets

[hell_bird]

Na Revolution ist wohl etwas zu viel.
IR bzw. IL gab es ja auch schon vorher, sowohl bei DirectX, bei OpenCL als auch z.B. intern bei AMD (eng an DirectX angelehnt, aber auch unified zwischen Grafik und Compute) und auch nV (PTX ist auch nur eine Intermediate Language in dem Sinne, daß das ein Pseudoassembly ist, welches die Hardware abstrahiert und vom Treiber noch per Compiler auf die eigentliche ISA gemappt wird).
Ja klar, ich meinte auch vor allem, dass es für die OpenGL/CL-Welt der ganz große Sprung ist und vielleicht am Ende wichtiger sein könnte als die API. Interessant fände ich vor allem wie es sich mit den anderen vergleicht. Immerhin ist es nicht direkt von LLVM übernommen wie OpenCL und hat den Vorteil der späten Geburt...

[Knuddelbearli]

es gibt doch zu AMD LiquidVR SDK infos .

http://www.pcper.com/files/imagecache/article_max_width/review/2015-03-03/06.jpg


http://www.pcper.com/reviews/Graphics-Cards/AMD-LiquidVR-SDK-Aims-Silky-Smooth-VR-all-Headsets

Das ist aber doch für VR wo ein guter Teil des Bildes für beide Augen gerendert werden muss oder?
Meine SFR wie im aktuellen CIv Beyount Earth

[Guest83]

Vulkan Debugger von LunarG und Valve:

miZmas6sGqM

[fondness]

Der Vulkan-API Talk auf der GDC startet in ~3min...

[d2kx]

http://i.imgur.com/lQ794wp.jpg

[Bl@de]

https://twitter.com/scottwasson
https://twitter.com/ryanshrout

Zwei Liveblogs von Redakteuren vom Panel inkl. Bildern und Videos.

[d2kx]

0Hth4u65zfc

DOTA 2 on Source 2 Engine on Linux using new Vulkan API

[Unicous]

https://twitter.com/scottwasson
https://twitter.com/ryanshrout

Zwei Liveblogs von Redakteuren vom Panel inkl. Bildern und Videos.


Merci.

[fondness]

Man bedankt sich noch mal ausdrücklich bei AMD für die Bereitstellung von Mantle. Den Mantle-Renderer auf Vulkan umzustellen soll "very easy" sein.

[Ludi]

Wenn Ballmer noch bei MS wäre, würden jetzt vermutlich einige Stühle durch die Gegend fliegen ;)

Es ist großartig, dass es endlich, nach all den Jahren, eine konkurenzfähige cross-platform API gibt.

[fondness]

Am Ende sollte es spannend werden^^

[Locuza]

Frostbite wird Vulkan verwenden und der erste shipping title wird Star Wars sein? :p

[Unicous]

Frostbite wird Vulkan verwenden und der erste shipping title wird Star Wars sein? :p

Goil.:eek:

:freak:

The @VulkanAPI thanks @AMD for giving it the Mantle API specs to start with. A LOT of thanks going into that. Then a round of applause.
https://twitter.com/ryanshrout/status/573543304593178625

@Mantle, die Vulkan-Randnotiz.

https://twitter.com/scottwasson/status/573555749361594369

Unlike previous GLs, Khronos will offer a Vulkan SDK.

[fondness]

Tja da ist die versprochene Open-Source API für alle Plattformen inkl. SDK und unabhängigem Konsortium von AMD. Alleine hätte Khronous wenn sie es überhaupt geschafft hätten sicher wieder Jahre benötigt.

[Eidolon]

Gefühlt rummst es da gerade gewaltig, das neue OpenGL Vulkan, dazu die breite Produktpalette von Valve inkl. SteamOs, SteamMachines, SteamLink, SteamController und haufenweise AAA Spiele Titel für Linux.
Bin mal gespannt, das wird einen Laden aus Redmond so gar nicht schmecken und das ist auch gut so!

[Bl@de]

Gefühlt rummst es da gerade gewaltig, das neue OpenGL Vulkan, dazu die breite Produktpalette von Valve inkl. SteamOs, SteamMachines, SteamLink, SteamController und haufenweise AAA Spiele Titel für Linux.
Bin mal gespannt, das wird einen Laden aus Redmond so gar nicht schmecken und das ist auch gut so!

Jap. Das ist ne super Entwicklung und ich freu mich riesig nach den Ankündigungen der letzten Zeit. Hoffe das wird alles gut^^
Das es Microsoft nicht schmeckt ist mir dabei herzlich egal :P

[Menace]

Ich freue mich für uns Spieler, dass das mit Vulkan zu funktionieren scheint und trotzdem bin ich genervt. Ich befürchte nämlich, dass AMD letztlich (im Gegensatz zu nvidia + intel) überhaupt nicht davon profitiert. Immerhin können sie sich über eine Runde Applaus freuen. :P

[Unicous]

@Eidolon

Diesen Ruck erwarte/erhoffe ich schon seit einer gefühlten Ewigkeit (und bin damit natürlich nicht der Einzige:tongue:). Aber bei Khronos kam einfach nichts bei rum und die Anstrengungen die Valve in den letzten Jahren betrieben hat, kann man im Nachhinein auch nur als halbherzig bezeichnen.

[HarryHirsch]

wurden denn schon titel angekündigt? wenn die unterstützung wie bei opengl und mantle ist sieht es trotzdem nicht gut aus.

[Loeschzwerg]

Tja da ist die versprochene Open-Source API für alle Plattformen inkl. SDK und unabhängigem Konsortium von AMD. Alleine hätte Khronous wenn sie es überhaupt geschafft hätten sicher wieder Jahre benötigt.

Wenn das in dieser Form das Ziel war, ok.

Wird man AMD auch zukünftig damit in Verbindung bringen? Vermutlich nicht. Kein Marketingeffekt, kein Gewinn. Business as usual.

Schön zu sehen wie viele Entwickler schon bei Vulkan an Bord sind :) Da geht was.

[Screemer]

wurden denn schon titel angekündigt? wenn die unterstützung wie bei opengl und mantle ist sieht es trotzdem nicht gut aus.
zumidest dota2 ist ja schon mal lauffähig und die nächsten frostbite titel werdens wohl auch unterstützen. ich wäre ja für ein update von da3 und bf4 :ugly:

[gixe]

Bin ja echt mal gespannt wie das in Zukunft bei AMD mit den Treibern und deren Optimierung für verschiedene Sachen läuft.
Schon heute hängt man bei linux hinterher und nvidia scheint irgendwie besser für dx11 zu optimieren.
In Zukunft heißt es dann oGL+Vulkan für Win + Linux und DX11 für legacy Win + DX 12.x für Win10 und Mantel will man auch noch irgedwie weiter supporten :eek:
Würde ja vermuten bei beschränkten Budget werden gewisse API/OS-Kombinationen nur stiefmütterlich behandelt.

[Lord_X]

In Zukunft heißt es dann oGL+Vulkan für Win + Linux und DX11 für legacy Win + DX 12.x für Win10 und Mantel will man auch noch irgedwie weiter supporten :eek:
Nö wieso?

Es sollte heissen:

Vulkan für Win + Linux und Mac :)

Alles andere braucht man nicht mehr, wenn man es mal ganz einfach betrachtet.

[Unicous]

wurden denn schon titel angekündigt? wenn die unterstützung wie bei opengl und mantle ist sieht es trotzdem nicht gut aus.

Valve wird alles Machbare sicherlich auf Vulkan portieren, die Dota 2 Demo zeigt es ja. Die großen Studios werden sich dann auch nicht lumpen lassen und ihre DX12 Spiele portieren vllt. gibt ja Valve auch einen Anreiz bei Steam, mit SPIR-V wird es sicherlich auch einfacher sein das zu realisieren.

Die großen Engines wollen/werden es unterstützen. Das könnte ein großer Wurf werden.


@gixe

AMD arbeitet seit längerer Zeit an einem komplett neuen Treiber für Linux, ich denke die Entwicklung glNext/Vulkan hat damit auch zu tun.

[HarryHirsch]

was ist mit der ue4? ich persönlich mag die zwar nicht weil sich die games mit ue irgendwie alle gleich "anfühlen" und aussehen aber damit kommt doch sicher wieder jedes zweite spiel

[x-dragon]

Demnach werden hier wohl auch einige Kandidaten dabei sind, oder?

http://store.steampowered.com/sale/steamos_sale

[Unicous]

@HarryHirsch

Epic hat an der Vulkan Spec mitgewirkt. Wäre doof sich davon dann zu distanzieren.

https://www.khronos.org/assets/uploads/apis/2015-vk-image-5.png

@x-dragon

Ich denke ein Bruchteil davon wird wirklich portiert, viele der Spiele sind ja auch schon relativ alt und es sind ja dennoch Kosten damit verbunden (Manpower).

Arkham Knight könnte ich mir z.B. vorstellen, vllt. auch The Witcher III. Viele der Titel "brauchen" es auch einfach nicht. FTL muss man jedenfalls nicht portieren.:tongue:

[HarryHirsch]

nen stream gibt es hier:

http://www.ustream.tv/channel/khronos-gdc

[Arcanoxer]

nen stream gibt es hier:

http://www.ustream.tv/channel/khronos-gdc
Cheers!

edit: zu früh gefreut, off air.

[Unicous]

Der Stream ist leider schon wieder down und lief nur ein paar Minuten. Es war auch nur ein Versuch laut dem Vulkan Twitter-Account. Mit einem Handy anscheinend.;D


Edit:

Wurde das hier irgendwann schon mal im Forum gepostet?

http://www.alexstjohn.com/WP/2014/06/08/direct3d-opengl-metal-full-circle/

Ist ein Abriss von Alex St. John (einer der Original-Architekten von D3D) wie aus "OpenGL" DirectX wurde.

[iuno]

Ich denke ein Bruchteil davon wird wirklich portiert, viele der Spiele sind ja auch schon relativ alt und es sind ja dennoch Kosten damit verbunden (Manpower).

Arkham Knight könnte ich mir z.B. vorstellen, vllt. auch The Witcher III. Viele der Titel "brauchen" es auch einfach nicht. FTL muss man jedenfalls nicht portieren.:tongue:
Meinst du das ernst? Wäre schon richtig dreist von Valve, die Titel im SteamOS Sale zu verkaufen und nachher sind sie nicht für die Plattform verfügbar. Für mich ist das schon recht eindeutig...
Hier (https://www.gamingonlinux.com/articles/lots-of-big-games-confirmed-for-steamos-torchlight-ii-now-out-payday-2-mordor-and-more-coming-too.5047) sind einige Aussagen von offizieller Seite aufgelistet, u.a. zu Shadow of Mordor, Payday 2, Saints Row IV, Company of Heroes 2, GRID Autosport, Total War™: ROME II und Magicka 2

[HarryHirsch]

Cheers!

edit: zu früh gefreut, off air.

ja schade. morgen um 12 cet geht es weiter.

[Unicous]

@iuno

Es ging doch um Vulkan? Der Rest bleibt einfach bei "OpenGL" und wird auf SteamOS portiert.

Vulkan macht doch nicht für jedes Spiel und jeden Entwickler Sinn. Ist genauso wie zuvor bei Mantle bzw. bei DX12.

[iuno]

Ach so natürlich. Sorry jetzt war ich raus, gedanklich im Valve Thread. Bitte nicht beachten ;D

[Unicous]

Scott Wasson hatte ja Live Twitter-Blog zu dem Vulkan Vortrag gemacht (obwohl ich Twitter dafür nicht ideal finde) und u.a. das von Johan Andersson zitiert:

.@repi: Will be easy to take our Mantle renderer and switch it to Vulkan instead.
https://twitter.com/scottwasson/status/573544840480231424

Hört sich sehr gut an. Die aktuellen und künftigen Mantle-Titel könnten also relativ einfach geswitcht werden indem die Shadersprache HLSL durch GLSL ausgetauscht wird.


Edit: Vulkan/SPIR-V "Session"

EUNMrU8uU5M

[HarryHirsch]

kzdwmba-gN0

für deutschland:

http://www.youtubeunblocker.org/permalink.php?url=d5D4zsG3n1yrwOe1CfU%2FGgpOMVqlAOKvGJhJyUWKE08%2FjpyR59nkN4LwN5 Y6GGMX3n9MDdkpNRk%2Fps2JTIar3p2giZy0dVCLYlnIPdGOyAlRa098yGmJ5HS5hG7ETndF

ist das nicht nen mobile-bench?

[-/\-CruNcher-/\-]

Am Ende sollte es spannend werden^^

Das war es mit Windows Spiele Bindung als argument für das OS und das gerade im Mobile und VR Kampf ;)

Valve hat das Geschaft wozu jahrelang keiner im Stande war Hut ab Herr Newell ;)

Natürlich wiegt die Gewöhnung an Visual Studio und der Windows UI bei vielen nach da werden nur die Nerds bei den Entwicklern ihren Spaß haben ;)

[SaschaW]

Die Slides sind online :

https://www.khronos.org/developers/library/2015-gdc

Über SPIR-V freu ich mich am meisten. Klingt fast noch besser als AZDO xD

[Grundkurs]

Edit: Vulkan/SPIR-V "Session"

http://youtu.be/EUNMrU8uU5M


Bei 57:47 gibt es ein Live-Example bei dem auf den Vulkan-Treiber geswitcht wird, da erkennt man gut die Entlastung der CPU.

[Guest83]

Gib jetzt auch die Slides zur Vulkan-Präsentation von der GDC: https://www.khronos.org/assets/uploads/developers/library/2015-gdc/Valve-Vulkan-Session-GDC_Mar15.pdf

[fondness]

DICE stellt auch noch mal unmissverständlich dar:

http://s21.postimg.org/sqdyo6ifb/Zwischenablage01.png (http://postimage.org/)

[Timbaloo]

Ist unterm Strich auch gut jetzt Mantle schnell zu beerdigen. Zu spät, zu viel versprochen, kein SDK. Mit Vulkan kann man Mantle jetzt in Würde sterben lassen.

[robbitop]

Ist Vulkan nicht eine riesen Chance für die Studios ihre (zukünftigen) Spiele noch einfacher auf verschiedenste Plattformen zu portieren? Wozu noch D3D(12) nutzen? Vulcan erlaubt die gleichen Möglichkeiten, ohne Altlasten und wäre auf vielen Plattformen lauffähig.

Schade, dass Spielkonsolen nicht mitziehen - dann wäre der Vorteil noch größer.

[Timbaloo]

Ich möchte nicht wissen was MS da im Hintergrund anzettelt um Entwickler zu "überzeugen".

Sehe das nämlich genauso. Etwas wie Vulkan für Eingabe-Ausgabe usw. wäre aber auch noch interessant. So dass man quasie den kompletten DX-Bereich abdecken kann.

[derF]

Ist unterm Strich auch gut jetzt Mantle schnell zu beerdigen. Zu spät, zu viel versprochen, kein SDK. Mit Vulkan kann man Mantle jetzt in Würde sterben lassen.
Du meinst: Mit Vulkan erfüllen sich die "Versprechungen" von Mantle und mehr.
Jetzt ist Mantle, zusätzlich zu dem Vorteil, den es vielen in den schon releasten Spielen gebracht hat, nicht mehr nur der Denkanstoß um Veränderung zu erwirken, sondern bald auch absolut praktisch umgesetzt für alle ein Gewinn.
Das ist definitiv keine Beerdigung.

[fondness]

Du meinst: Mit Vulkan erfüllen sich die "Versprechungen" von Mantle und mehr.
Jetzt ist Mantle, zusätzlich zu dem Vorteil, den es vielen in den schon releasten Spielen gebracht hat, nicht mehr nur der Denkanstoß um Veränderung zu erwirken, sondern bald auch absolut praktisch umgesetzt für alle ein Gewinn.
Das ist definitiv keine Beerdigung.

Zumal AMD von Anfang an gesagt hat, dass genau das das Ziel ist.

[Arcanoxer]

Zumal AMD von Anfang an gesagt hat, dass genau das das Ziel ist.
Aus einer Niederlage ein (PR)Erfolg zu machen, da gehört schon was zu.
Warum sollte AMD genau das gewollt haben? Praktisch keine Kontrolle mehr über die API.

Wie auch immer, Mantle ist Geschichte und das hier ist auch der Vulkan thread. ;)

[Unicous]

Haben wir alles schon mal besprochen (u.a. im Mantle-Thread) Arcanoxer. Du verschließt dich einfach den Fakten und machst so weiter. Johan Andersson hatte von Anfang an die Vision einer offenen API und so ist es auch gekommen.


Übrigens ist das der Vulkan-Thread. Mantle ist weiter am Leben und weiterhin ein Kleinkind, aber das tut hier nicht viel zur Sache.

[robbitop]

Es hätte für Mantle als IHV spezifische API sowieso keine realistische Chance gegeben, wirklich breite Verbreitung zu finden. Der Schritt zu Vulkan war gut und richtig und passt absolut in AMDs Handlungen, offene und freie Standards zu generieren.

[Locuza]

Ist Vulkan nicht eine riesen Chance für die Studios ihre (zukünftigen) Spiele noch einfacher auf verschiedenste Plattformen zu portieren? Wozu noch D3D(12) nutzen? Vulcan erlaubt die gleichen Möglichkeiten, ohne Altlasten und wäre auf vielen Plattformen lauffähig.

Schade, dass Spielkonsolen nicht mitziehen - dann wäre der Vorteil noch größer.
Ich warte da lieber die Praxis ab.

DX12 ist früher da, teilt sich dann fast alle Gemeinsamkeiten mit der Xbox One, hat gute Tools von MS.

Vulkan muss ebenso eine robuste Entwickler-Umgebung darstellen.
Ich denke mittel- bis langfristig kommt man dahin und wird die Theorie auch irgendwann umsetzen.
Etwas was OGL für immer verwehrt blieb.

[Terrarist]

Ist Vulkan nicht eine riesen Chance für die Studios ihre (zukünftigen) Spiele noch einfacher auf verschiedenste Plattformen zu portieren? Wozu noch D3D(12) nutzen? Vulcan erlaubt die gleichen Möglichkeiten, ohne Altlasten und wäre auf vielen Plattformen lauffähig.

Stimmt, da sprchicht nicht mehr wirklich viel für DX12.


Schade, dass Spielkonsolen nicht mitziehen - dann wäre der Vorteil noch größer.

Bei Sony kann ich mir gut vorstellen dass sie mitziehen, die sind ja vor allem auch für VR auf Indie Entwickler angewiesen, und so stark unterscheiden sich Linux und FreeBSD jetzt nicht. Da hätten es Entwickler relativ einfach von SteamOS zur PS4 und umgekehrt zu portieren. Das ist eigentlich in Sonys Sinn Vulkan zu nutzen.

[Unicous]

Vulkan ist die erste OGL-"Version" bei der ein SDK mitgeliefert wird, man hat sich sehr viele Gedanken um die Entwickler-Umgebung und Dokumentation gemacht. Olle Graham Sellers will auch ein Buch drüber schreiben ( nach dem Kassenschlager "OpenGL SuperBible: Comprehensive Tutorial and Reference":freak:)

[fezie]

Ich warte da lieber die Praxis ab.

DX12 ist früher da, teilt sich dann fast alle Gemeinsamkeiten mit der Xbox One, hat gute Tools von MS.

Vulkan muss ebenso eine robuste Entwickler-Umgebung darstellen.
Ich denke mittel- bis langfristig kommt man dahin und wird die Theorie auch irgendwann umsetzen.
Etwas was OGL für immer verwehrt blieb.


DX 12 ist aber Win 10. und eventuell 8.1 only
Vulkan kann es auch noch für Win 7 theoretisch geben

[StefanV]

DX 12 ist aber Win 10. und eventuell 8.1 only
Vulkan kann es auch noch für Win 7 theoretisch geben
Glaubst du wirklich, dass das noch für 8.1 kommen wird?
Ich nicht...

Und vorallen: Wo soll denn der Sinn von 11.3 liegen, wenn es DX12 auch für 8.1 gibt?!

[Unicous]

DX12 gibts nur für Win10.

[fezie]

Keine Ahnung. Deswegen ja das eventuell.
Win 8 hab ich eh nicht
Ich würde mich viel mehr freuen, wenn es jetzt mehr top games für Linux gibt :)

[Shink]

Ich würde mich viel mehr freuen, wenn es jetzt mehr top games für Linux gibt :)
Ehm... das wird wohl eher nicht passieren denke ich (außer du meinst mit "Linux" auch "Android").

Aber zumindest hat Wine dann in Zukunft weniger zu tun. Wesentlich weniger.

[Eidolon]

Ehm... das wird wohl eher nicht passieren denke ich (außer du meinst mit "Linux" auch "Android").

Aber zumindest hat Wine dann in Zukunft weniger zu tun. Wesentlich weniger.

Och so ein paar große Ankündigungen gibt es da schon.

[fezie]

Mordors Schatten ja zB.
Aber mir wären in der Tat auch Win only Vulkan Spiele recht.
Geht ja mit wine dann ja auch gut. So wie mit OpenGL. Aber das hat ja leider bei Spielen stark an Bedeutung verloren

[RLZ]

Ist Vulkan nicht eine riesen Chance für die Studios ihre (zukünftigen) Spiele noch einfacher auf verschiedenste Plattformen zu portieren? Wozu noch D3D(12) nutzen? Vulcan erlaubt die gleichen Möglichkeiten, ohne Altlasten und wäre auf vielen Plattformen lauffähig.
Wenn API X überall verfügbar ist, wäre das möglich

Relevante Plattformen für AAA Games: PS4, XBone, Windows
Das macht 2 Plattformen mit DX12, eine mit Vulkan und eine mit keiner von Beiden. :D

Relevante Plattformen für Mobile: Android, iOS
Hier haben wir eine Plattform mit Vulkan und eine mit Metal.

-> Ohne Abstraktionslayer kommen wir kurzfristig eh nicht aus.

[sth]

Vulkan-Session mit lesbaren Slides: https://www.youtube.com/watch?v=qKbtrVEhaw8

[Terrarist]

Ehm... das wird wohl eher nicht passieren denke ich (außer du meinst mit "Linux" auch "Android").

Kann mir vorstellen dass Valve dafür sorgt dass VR auf SteamOS (und damit Linux) eine gute Rolle spielt und quasi eine Zielplattform für VR wird. Immerhin kann sich ein VR interessierter dann eine geeignete Steammachine kaufen, dazu Headset und Controller. Plug & Play, ohne Windows aufzusetzen und Treiber zu suchen.

Sehr wahrscheinlich wird es Steammachines in einem tragbaren mATX Gehäuse (z.B. von Corsair) mit Dual GPU's geben. Bestimmt nicht billig, aber es wird genug geben die es sich leisten würden, und dann sogar extra einen Raum für VR locker rmachen.

Es ist ja irgendwie schon komisch dass Gaming bis jetzt entweder mit hohem Konfigurationsaufwand verbunden ist, oder sich nur auf Konsolen mit begrenzter Leistung im Billigbereich abspielt. Also entweder nur etwas für Nerds oder Kinder/Teenager ist.

[Guest83]

Vulkan-Vorstellung auf der GDC: http://www.gdcvault.com/play/1022018/

[Kriton]

Jetzt wird es auch "außerhalb" bekannt:

http://blog.fefe.de/?ts=abcd31f5

[Guest83]

Hä?

[fezie]

Ich frag mich eh immer was alle an dem fefe so toll finden
Also heise Leser wissen schon lang von Vulkan. Also keine Ahnung was du mit außerhalb meinst
Außerhalb der Gamer Szene ist Vulkan eh nicht so interessant

[Skysnake]

Würde ich nicht unbedingt sagen. Viele CADler dürften sich wohl freuen.

[fezie]

Ach ja. An die hab ich jetzt nicht gedacht
Aber trotzdem frag ich mich was so toll daran sein soll wenn fefe das erwähnt
Vielleicht sollt ich darüber einen neuen Thread aufmachen

[Kriton]

Es geht um Reichweite im Hinblick auf die Kenntnis, dass Vulkan eine Ableitung von Mantle ist. Man kann von ihm halten was man will, aber viele lesen ihn.

[Timbaloo]

Trifft auf die Bild-Zeitung auch zu.

[Pirx]

Trifft auf die Bild-Zeitung auch zu.
:freak: irgendwo sollte man bei Vergleichen auch mal eine Grenze ziehen können.

[Coda]

Würde ich nicht unbedingt sagen. Viele CADler dürften sich wohl freuen.
CAD? Das ich nicht lache. Die CAD-Leute sind diejenigen, die immer verhindert haben, das der alte Scheiß mal aus GL rausfliegt.

Wenn da was zu Vulkan wechselt fress ich nen Besen.

[Skysnake]

Das glaube ich dir sogar aufs Wort, denn die GUIs sind teilweise aus der Hölle...

Was ich da schon teils an verdammt schlecht programmierten GUIs gesehen habe ist nicht mehr feierlich.

Ich hoffe daher, dass die auf Vulkan umsteigen, und damit sich die Performance bessert, da man eben nicht mehr so schludern kann, aber so lange da keiner den ersten Schritt macht, oder die Kunden Druck machen, schwant mir weiterhin stillstand.

[Nightspider]

CAD? Das ich nicht lache. Die CAD-Leute sind diejenigen, die immer verhindert haben, das der alte Scheiß mal aus GL rausfliegt.

Wenn da was zu Vulkan wechselt fress ich nen Besen.

Wieso? Kenne mich da überhaupt nicht aus und musste CAD auch bisher nur ein mal an der Uni benutzen.

[Coda]

Ich denke nicht, dass OpenGL/Direct3D wirklich das Performance-Problem bei CAD-Applikationen ist.

Die Leute dort sind wahrscheinlich nicht wirklich Spezialisten was Low-Level-Programmierung angeht, ich weiß nicht ob die mit Vulkan zurecht kommen. Ich weiß nicht ob dir das bewusst ist, aber mit Vulkan darfst du dir für dynamische Vertex-Daten selber einen Allokator mit GPU/CPU-Fences und Online-Defragmentierung schreiben. Selbst in der Spiele-Industrie wird's da dünn.

Es gibt einen Grund warum Microsoft DX11 weiter mit Features versehen möchte und so lange keine Low-Level-API wollte. Wäre Mantle nicht gekommen hätten die daran fest gehalten, einfach weil sie sowas von der Philosophie den Leuten nicht zumuten möchten.

[Skysnake]

Täte aber denke ich so mancher Firma gut.

Wenn ich erlebe, das die Anzeige in einem Fenster das komplette Programm freezen lässt, dann fass ich mir schon an den Kopf -.-

[Coda]

Und die Leute wachsen auf Bäumen? Da gibt es definitiv einen Fachkräftemangel.

[Skysnake]

Nein, aber wenn es solche APIs gibt, wird es auch zwangsläufig Leute geben, die sich damit beschäftigen, und gerade beim Nachwuchs sollte sich das positiv bemerkbar machen, wenn die neuen APIs eben mehr einfordern, dann leisten die auch mehr. Wer mit Grafik was machen will, wird deswegen ja nicht auf was ganz anderes umschwenken, sondern den Frosch wohl schlucken.

Bzgl. Fachkräftemangel, haste aber wahrscheinlich recht. Als C/C++ Programmierer, der auf Lowlvl steht nen Job zu finden, scheint nicht schlecht all zu schwer zu sein.

[Coda]

Ich seh das pessimistischer. Man gibt den Unfähigen und Unerfahrenen mehr Seil um sich zu erhängen.

[Guest83]

Wieso kann man nicht einfach in einem API beides unterstützen? Einen Pfad der geschlossener und damit einfacher zu bedienen ist, aber auch weniger Optimierungspotential bietet und einen anderen, der eben offen ist?

[Exxtreme]

Wieso kann man nicht einfach in einem API beides unterstützen? Einen Pfad der geschlossener und damit einfacher zu bedienen ist, aber auch weniger Optimierungspotential bietet und einen anderen, der eben offen ist?
Das gibt es ja. Die alten APIs verschwinden ja erstmal nicht. Zudem betrifft das auch eher die Leute, die Engines produzieren.

[Guest83]

Das gibt es ja. Die alten APIs verschwinden ja erstmal nicht. Zudem betrifft das auch eher die Leute, die Engines produzieren.
Ja, aber OpenGL hat doch seine eigenen Probleme mit den Altlasten, dass es ja für "Anfänger" oder kleinen Teams mit geringem Budget erst wieder keine brauchbare Alternative ist. Vulkan soll ja nicht nur durch den Low-Level-Bereich punkten, sondern dass es erstmals auch ordentliche Tools und Debugger dafür geben soll. Soweit ich das verstanden hab, war es ja genau dieser Bereich, wo Microsoft immer die Nase vorn hatte und DirectX deshalb beliebter bei vielen Entwicklern war.

[Exxtreme]

Ja, aber OpenGL hat doch seine eigenen Probleme mit den Altlasten, dass es ja für "Anfänger" oder kleinen Teams mit geringem Budget erst wieder keine brauchbare Alternative ist. Vulkan soll ja nicht nur durch den Low-Level-Bereich punkten, sondern dass es erstmals auch ordentliche Tools und Debugger dafür geben soll. Soweit ich das verstanden hab, war es ja genau dieser Bereich, wo Microsoft immer die Nase vorn hatte und DirectX deshalb beliebter bei vielen Entwicklern war.
Naja, für Anfänger ist eine fertige Engine ala Unity oder Hero Engine wohl die beträchtlich bessere Alternative. Ausserdem kann man davon ausgehen, dass es sehr schnell Bibliotheken geben wird, die das Lowlevel-Rumgefummle wegabstrahieren.

[sth]

Ich seh das pessimistischer. Man gibt den Unfähigen und Unerfahrenen mehr Seil um sich zu erhängen.
Selbiges sagen z.B. Java-Leute auch über manuelles Memory Management... und feiern anschließend 50ms dauernde Garbage Collection Cycles in der neuen Android VM als tolle Verbesserung. ;)

Natürlich gebe ich dir mit deiner Aussage grundsätzlich recht, aber ob das unter'm Strich wirklich schlimmer ist als die derzeitige Situation, wage ich dennoch zu bezweifeln, zumindest zum derzeitigen Zeitpunkt. Wenigstens hat man die Dinge dann mehr oder weniger selbst in der Hand, oder zumindest ist es das, was Vulkan verspricht.

nV und AMD haben unter Windows zwar mittlerweile "gute" OpenGL-Treiber, aber bei allem was darüber hinausgeht (andere Plattformen und Hersteller) ist die Treiberqualität bekanntlich immernoch... *zusammenreiß* nennen wir's mal "variierend". Und das natürlich am meisten auf den Plattformen, die sich am schlechtesten debuggen lassen...

Klar ist Vulkan prinzipiell komplexer als OpenGL, aber ich vermute, dass wir sehr schnell Utility-Libraries für einige Bereiche sehen werden (quasi sowas wie GLU). In der Vulkan-Präsentation wurde ja auch schon auf das Thema eingegangen: Khronos geht nicht davon aus, dass die meisten Entwickler alles 100% low-level schreiben werden. Allerdings wird es wohl erstmal keine "offizielle" Utility-Lib geben.

[Chris Lux]

Ich dachte immer es wäre vorgesehen irgendwann eine offizielle "Layered" Lib zu haben. Sogar soweit, dass OpenGL auf Vuklan aufsetzt und man eben eine einzelne, offene OpenGL Runtime hat.

[sth]

Mal sehen, was man über die Layer alles machen können wird. In den Talks wurden soweit ich weiß bisher immer nur Layer beleuchtet, die zwischen Vulkan API und Treiber liegen, also z.B. zusätzliche Debugging- oder Validation-Layer. Wie das mit "higher level" Layern aussieht weiß ich nicht.

Eine OpenGL-Implementierung auf Vulkan-Basis klingt interessant. Wird vermutlich ein Stück langsamer sein als die nativen OpenGL-Treiber der großen Hersteller, aber für Hersteller mit Gammeltreibern wäre es evtl. sogar eine Verbesserung.

[fezie]

Wieso sollte OpenGL auf Vulkan Basis besser funktionieren als direktes OpenGL? Wenn man schon für OpenGL keine guten Treiber hinbekommt dann besteht ja nicht soviel Hoffnung dass die Vulkan Treiber besser werden
Einfacher zur Wartung ist es natürlich nur für Vulkan + DirectX direkten Support im Treiber zu haben. Und OpenGL dann komplett von jemand anderem implementieren zu lassen
So wie unter Linux mit Mesa

[Nightspider]

Machen nicht gerade Firmen wie die CAD Ersteller haufen Asche? Die sollen sich doch gute Low-Level-Programmierer besorgen können und zur Not bestehende Programmierer ordentlich weiterbilden.

[aufkrawall]

Ich seh den Sinn für so einen Paradigmenwechsel nicht.
Sind die CAD-Anbieter mit dem bisherigen professionellen OGL-Support so schlecht gefahren?

[Nightspider]

Auf jeden Fall sind viele Arbeitsprogramme diverser Firmen optisch und von der Bedienung bzw. den Einstellungsmöglichkeiten gefühlt auf einem Level wie Windows 2000. ^^

Ich hoffe mal das durch die HighDPI Umstellung* viele Firmen bei ihren Programmen mittelfristig das GUI überarbeiten werden.

Hat jetzt vllt nicht viel mit dem Topic LowLevel zu tun aber vllt gäbe es da noch andere Vorteile die genutzt werden könnten.

*4K Displays werden sich sicherlich rasch durchsetzen wenn die Preise erstmal gefallen sind. Irgendwann gibts zu jedem Komplett PC auch 4K Monitore. Dazu müssten sich die Preise der 4K Display gerade mal halbieren.

[Chris Lux]

Wieso sollte OpenGL auf Vulkan Basis besser funktionieren als direktes OpenGL? Wenn man schon für OpenGL keine guten Treiber hinbekommt dann besteht ja nicht soviel Hoffnung dass die Vulkan Treiber besser werden...
Weil Vulkan verglichen mit OpenGL keine komplexe Runtime benötigt weil es viel näher an der aktuellen Hardware ist. Das soll heißen, dass es keine gigantische State-Machine mehr nachbilden und bei jedem wichtigen Call einen riesigen State-Vektor validieren muss. Dazu müssen sie keinen High-Level Shader-Compiler mehr liefern sondern nur noch Low-Level SPIR-V unterstürtzen. Warum haben wohl auf der GDC viele Vulkan-Demos zeigen können? Weil die IHVs relativ schnell einen Vulkan-Treiber basteln konnten.

Eine offene von Khronos offiziell unterstützte OpenGL Runtime würde eben bedeuten, dass die IHVs nur Vulkan liefern müssen und OpenGL direkt könnten ;). Wunschträume.

[Demirug]

Eine offene von Khronos offiziell unterstützte OpenGL Runtime würde eben bedeuten, dass die IHVs nur Vulkan liefern müssen und OpenGL direkt könnten ;). Wunschträume.

Khronos hat nicht die Ressourcen um sowas zu stemmen.

[Chris Lux]

Khronos hat nicht die Ressourcen um sowas zu stemmen.
Genauso wie sie den GLSL-to-SPIR-V Compiler vorher nie hätten stemmen können. Oder den Vulkan-Debugger den Valve sponsert. Mal sehen was sich so auftut, mit dem Mobile-Markt im Rücken ist vielleicht was möglich.

[Coda]

Weil Vulkan verglichen mit OpenGL keine komplexe Runtime benötigt weil es viel näher an der aktuellen Hardware ist.
Hä? Aber genau das musst du doch dann in der OpenGL-Abstraktionsschicht machen. Warum soll das schneller sein als im Treiber?

Sorry, aber das ergibt null Sinn. Wenn überhaupt wäre der Gewinn, das man den OpenGL-Teil nur einmal schreiben muss und der IHV nur Vulkan. Das halte ich in der Tat für sinnvoll.

Selbiges sagen z.B. Java-Leute auch über manuelles Memory Management... und feiern anschließend 50ms dauernde Garbage Collection Cycles in der neuen Android VM als tolle Verbesserung. ;)
Und wieviel Millionen Sicherheits-Bugs haben wir jedes Jahr, weil die Leute C/C++ programmieren und es nicht können? Scheiß Beispiel.

[Marscel]

Hä? Aber genau das musst du doch dann in der OpenGL-Abstraktionsschicht machen. Warum soll das schneller sein als im Treiber?

Seh ich genauso. Ich hab mir das Setup aus etwas OpenGL 1 und 3 Erfahrung angeguckt, und war nicht nur davon angetan, Speicherbuchhaltung, State-Transitions und Command Queues immer und ständig selbst verwalten zu müssen.

Ohne den Sinn in Frage zu stellen, aber aus pragmatischen Gründen (bei mir in erster Linie Visualisierung) würde ich mir doch gerne eine gewisse Abstrahierung wünschen.

[Skysnake]

Und wieviel Millionen Sicherheits-Bugs haben wir jedes Jahr, weil die Leute C/C++ programmieren und es nicht können? Scheiß Beispiel.
Wobei darauf auch zumindest im Studium auch Null wert gelegt wird im Allgemeinen. Wenn musste dir da wohl gezielt das Wissen aneigenen. Da seh ich ein krukturelles Problem.

Ich habe z.B. auch keine Ahnung, was ich machen muss um sicher zu sein, dass da nichts schief geht, aber ich habe auch keine Ahnung, wo ich da anfangen müsste, mir die entsprechenden Sachen anzulesen. (Mal ganz abgesehen davon, das man Systemeingaben von Nutzern prüft, wenn man irgendetwas Sicherheitskritisches macht.)

[sth]

Wieso sollte OpenGL auf Vulkan Basis besser funktionieren als direktes OpenGL?
Eines der Hauptbestreben von Vulkan ist es, die Komplexität der Treiber zu reduzieren. Aktuelle OpenGL-Treiber müssen im Hintergrund alle möglichen Verrenkungen machen, da die Art wie die API funktioniert kaum etwas damit zu tun hat, wie die Hardware funktioniert.

Natürlich würde man bei einer OpenGL-on-Vulkan-Implementierung diese Komplexität nicht vermindern, sondern nur verlagern. Allerdings wäre sie in etwas verlagert, was herstellerübergreifend und damit relativ konsistent funktioniert.

Allerdings sollte man bei all diesen Gedankenspielen nicht vergessen, dass eine OpenGL-on-Vulkan-Implementierung in der Praxis sicher deutlich langsamer sein wird als jeder native Treiber und man trotzdem noch auf einen guten Vulkan-Treiber angewiesen wäre.

Und wieviel Millionen Sicherheits-Bugs haben wir jedes Jahr, weil die Leute C/C++ programmieren und es nicht können? Scheiß Beispiel.
Zugegeben nicht das beste.

[Chris Lux]

Hä? Aber genau das musst du doch dann in der OpenGL-Abstraktionsschicht machen. Warum soll das schneller sein als im Treiber?
Nicht schneller, das ist nicht der Punkt. Der IHV schreibt im Grunde keine OpenGL-Runtime mehr, sondern liefert nur noch die Vulkan-Implementierung.


Sorry, aber das ergibt null Sinn. Wenn überhaupt wäre der Gewinn, das man den OpenGL-Teil nur einmal schreiben muss und der IHV nur Vulkan. Das halte ich in der Tat für sinnvoll.
Das ist der Punkt. Somit können 'Ninjas' Vulkan coden und der Rest kann sich auf eine verlässliche OpenGL-Implementierung stürzen.

Eines der Hauptbestreben von Vulkan ist es, die Komplexität der Treiber zu reduzieren. Aktuelle OpenGL-Treiber müssen im Hintergrund alle möglichen Verrenkungen machen, da die Art wie die API funktioniert kaum etwas damit zu tun hat, wie die Hardware funktioniert.

Natürlich würde man bei einer OpenGL-on-Vulkan-Implementierung diese Komplexität nicht vermindern, sondern nur verlagern. Allerdings wäre sie in etwas verlagert, was herstellerübergreifend und damit relativ konsistent funktioniert.
Das ist genau was ich meinte, sorry wenn es nicht rüber kam ;).

[Coda]

Wobei OpenGL dann immer noch grässlich ist. Mir wär's lieber wenn sie nur pures OpenGL 4.5 drauf setzen.

[Chris Lux]

Wobei OpenGL dann immer noch grässlich ist. Mir wär's lieber wenn sie nur pures OpenGL 4.5 drauf setzen.
Jep. Mir auch. Für den Compatibility-Profile Kram gibt es ja noch Regal [1].

[1] https://github.com/p3/regal

[SaschaW]

Khronos hat nicht die Ressourcen um sowas zu stemmen.

Deshalb macht Khronos es mit Vulkan ja jetzt anders. Darf leider nicht zu sehr ins Detail gehen, aber die holen momentan genau die richtigen Leute mit ins Boot, und zwar nicht nur die dicken Brocken aus der Industrie sondern auch ganz andere Leute, die dann nicht nur zur API beitragen dürfen, sondern auch zum umgebenden Ökosystem, zu dem auch Tools etc. gehören.

Ob das zu einer offenen Implementiertung (bzw. ICDs) führt sei mal dahingestellt, aber das Ökosystem wird deutlich offener, und damit dynamischer als das System rund um OpenGL. Mal ganz davon abgesehen dass Treiber jetzt viel schlanker werden. Das ist nicht nur gut für die Performance, sondern v.a. auch was Wartung und Bugfixing angeht. Man muss sich ja nurmal ansehen was z.B. ein NVIDIA-Treiber bei einem einfachen glClear machen muss. Das sind mehrere tausend Zeilen Code und ganz viele Codezweige die dahinterstecken ;)

Und wer eh schon aktuelles OpenGL macht (AZDO, SSBO, UBO, etc. ftw. ;)) wird sich mit Vulkan ganz schnell zurechtfinden und OpenGL schnell hinter sich lassen. Mit AZDO verlässt man ja auch unter OpenGL die sichere Zone und ist dann mit Commandbuffers und Co. genau da wo Vulkan ist, nur dass es in Vulkan endlich wieder eine saubere, schlanke und durchdachte API ohne den alten Kram gibt. Und zwar auf allen verbreiteten Plattformen :smile:

[Coda]

Vulkan's Speichermanagement ist wesentlich härter als das von DX11/OpenGL 4 wenn man dynamische Buffer verwendet.

Sprich: Man muss es selber machen. Ich weiß nicht ob man sich da so schnell damit zurechtfindet. Da wird einem echt viel zugemutet, vor allem CPU/GPU-Parallelität, die vorher ganz gut wegabstrahiert war.

[Chris Lux]

Gut, oder zu sehr? ; )

Ich denke da an das Ratespiel wann ein Buffer georphaned war oder nicht. Mir persönlich kann an an so einer Stelle nicht explizit genug sein.

[del_4901]

Das Speichermanagement ist nicht so komliziert. Gibt hier und da ein paar Quirks, aber besonders kompliziert ist es nicht. Multi Device ist da schon etwas komplizierter.

[Coda]

Das Speichermanagement wird dann spaßig wenn du dynamische Vertex/Texture/Whatever-Daten hast die fragmentieren können und du nur defragmentieren kannst wenn die GPU die Daten nicht mehr verwendet. Darfst du alles manuell syncen.

Solche Sachen kann der DX11-Treiber selber machen. DISCARD und gut ist (gibt natürlich bessere Wege, aber es geht).

[del_4901]

Das Speichermanagement wird dann spaßig wenn du dynamische Vertex/Texture/Whatever-Daten hast die fragmentieren können und du nur defragmentieren kannst wenn die GPU die Daten nicht mehr verwendet. Darfst du alles manuell syncen.

Solche Sachen kann der DX11-Treiber selber machen. DISCARD und gut ist (gibt natürlich bessere Wege, aber es geht). Map DISCARD braucht man nicht unbedingt. Das ist eher fuer DescriptorSets interessant, aber das kann man auch anders loesen. Und dann ist auch die Frage wann die Engine ueberhaupt Updates erlaubt bzw. wann Sie ausgefuert werden. Fragmentierung war nie ein Problem fuer uns, da die Menge der dynamischen Ressourcen im Verhaeltniss zum Speicher ueberschaubar sind. Alternativ kann man auch einfach mit der GPU (copy-)defragmentieren dann braucht man nicht zu syncen.

[Coda]

Ein GPU copy löst das Problem nicht. Erstens sind die bei Vulkan auch asynchron und zweitens muss dafür die CPU trotzdem wissen was nicht mehr benutzt wird um den Speicher wieder freizugeben.

Ohne Defragmentierung musst du den Pool größer machen für die gleiche effektive Residency, damit verschenkt man Speicher.

[del_4901]

Ein GPU copy löst das Problem nicht. Erstens sind die bei Vulkan auch asynchron und zweitens muss dafür die CPU trotzdem wissen was nicht mehr benutzt wird um den Speicher wieder freizugeben.
Die Queues werden synchron abgearbeitet, wenn man eine Resourcetransition vergessen hat, dann ist es einfach ein Bug, das muss man naemlich eh machen. Alle deletes werden einfach ein paar Frames (RenderaheadLimit) verzoegert, dann kann man die getrost loeschen.

Ohne Defragmentierung musst du den Pool größer machen für die gleiche effektive Residency, damit verschenkt man Speicher. Wenn die dynamischen Pools nur ein paar wenige MB gross sind dann ist der extra Verschnitt zu verschmerzen. Zumal Map DISCARD zu implementieren auch kein Hexenwerk ist wenn man temporal linear allocation auf Sysmem Seite verwendet.

[Coda]

Ich rede zum Beispiel von GB großen Texture Stream Pools.

[del_4901]

Ich rede zum Beispiel von GB großen Texture Stream Pools.
Die mapt man eh nicht mit DISCARD. Und in deren fall nimmt man Vmem dann kann man auf Page ebene defragmentieren. Und das macht man auch nur wenn wirklich der Speicher knapp wird, und auch nur an einer gesonderten Stelle im Frame.

[kruemelmonster]

Auch wenn das Schwein nicht viel vom Uhrwerk versteht in das es da blickt, so findet es die Vorgänge da drin doch sehr interessant.

Mit der Zeit hat es sogar schon gelernt Zahnräder von Federn zu unterscheiden, daher freut es sich immer tierisch wenn Uhrenmacher etwas fachsimpeln. :up:

[SaschaW]

Sprich: Man muss es selber machen. Ich weiß nicht ob man sich da so schnell damit zurechtfindet. Da wird einem echt viel zugemutet, vor allem CPU/GPU-Parallelität, die vorher ganz gut wegabstrahiert war.

Komplett selber nicht (mehr, einen direkten Zugriff auf den Heap gibt es nicht mehr). Der Treiber hat jetzt ein Wörtchen mitzureden, und es gibt entsprechende Funktionen und Objekte die das Speichermanagement etwas "einfacher" machen, inkl. "Sub-Allocations". So weit weg von dem was man mit UBOs und SSBOs in modernem OpenGL macht ist das dann auch nicht mehr.

Aber Speichermanagement gehört eh zu den Grundlagen der Softwareentwicklung, und je weniger einem die API da dazwischen funkt, desto besser. Klar werden Einsteiger teilweise böse auf die Nase fallen, aber das ist ja woanders auch so :freak:

Und was man bei der aktuellen Diskussion nicht vergessen darf : Die Vulkan Spec ist ja noch lange nicht fertig, und grade in dem Bereich wird sich bis zum Release auch noch Einiges tun.

[fezie]

Auch wenn das Schwein nicht viel vom Uhrwerk versteht in das es da blickt, so findet es die Vorgänge da drin doch sehr interessant.

Mit der Zeit hat es sogar schon gelernt Zahnräder von Federn zu unterscheiden, daher freut es sich immer tierisch wenn Uhrenmacher etwas fachsimpeln. :up:

Geht mir genauso. Mit Grafik Programmierung hab ich mich nie beschäftigt. Aber trotzdem ist es interessant

[Coda]

Komplett selber nicht (mehr, einen direkten Zugriff auf den Heap gibt es nicht mehr). Der Treiber hat jetzt ein Wörtchen mitzureden, und es gibt entsprechende Funktionen und Objekte die das Speichermanagement etwas "einfacher" machen, inkl. "Sub-Allocations". So weit weg von dem was man mit UBOs und SSBOs in modernem OpenGL macht ist das dann auch nicht mehr.
Dann unterscheidet es sich aber schon mehr von Mantle als gedacht?

[fondness]

Aber Speichermanagement gehört eh zu den Grundlagen der Softwareentwicklung, und je weniger einem die API da dazwischen funkt, desto besser.

Meine Worte.

[del_4901]

Dann unterscheidet es sich aber schon mehr von Mantle als gedacht?
Bedank dich bei den ****** und deren komischen Memory Management.

[SaschaW]

Dann unterscheidet es sich aber schon mehr von Mantle als gedacht?

Wie gesagt alles unter Vorbehalt (da noch nicht fertig). Aber ja, den direkten Heap-Zugriff wie in Mantle wird es in Vulkan vermutlich nicht mehr geben (will/darf nicht ins Detail gehen).

Wird jeder Entwickler vermutlich anders drüber denken, aber es ist auch nicht ausgeschlossen dass es neben der Abstraktionsebene evtl. doch noch direkten Heap-Zugriff wie in Mantle geben wird.

Und auch wenn Vulkan quasi auf Mantle basiert, sollte man die evtl. nicht immer vergleichen. Die Vulkan API ist ja noch in der Mache, und da wird am Ende halt nicht ein Mantle 1.x o.ä. rauskommen, allein schon weil die Gruppe der Entscheider ja jetzt viel größer ist und alle IHVs beinhaltet.

[Coda]

Meine Worte.
Speichermanagment vielleicht, aber ein Bruchteil schreibt eigene Allocators.

Wie gesagt alles unter Vorbehalt (da noch nicht fertig). Aber ja, den direkten Heap-Zugriff wie in Mantle wird es in Vulkan vermutlich nicht mehr geben (will/darf nicht ins Detail gehen).
Meh.

[D4ve]

Und auch wenn Vulkan quasi auf Mantle basiert, sollte man die evtl. nicht immer vergleichen. Die Vulkan API ist ja noch in der Mache, und da wird am Ende halt nicht ein Mantle 1.x o.ä. rauskommen, allein schon weil die Gruppe der Entscheider ja jetzt viel größer ist und alle IHVs beinhaltet.

Wann ist denn mit einer final spec zu rechnen? Zur SIGGRAPH?

[SaschaW]

Wann ist denn mit einer final spec zu rechnen? Zur SIGGRAPH?

Zu Terminen kann ich keine Auskunft geben ;)

[BigKid]

Wobei darauf auch zumindest im Studium auch Null wert gelegt wird im Allgemeinen. Wenn musste dir da wohl gezielt das Wissen aneigenen. Da seh ich ein krukturelles Problem.

Ich habe z.B. auch keine Ahnung, was ich machen muss um sicher zu sein, dass da nichts schief geht, aber ich habe auch keine Ahnung, wo ich da anfangen müsste, mir die entsprechenden Sachen anzulesen. (Mal ganz abgesehen davon, das man Systemeingaben von Nutzern prüft, wenn man irgendetwas Sicherheitskritisches macht.)

Defensiv programmieren. Und das kostet Zeit und keiner macht es mehr...
Im Prinzip darfst du dich weder bei Benutzereingaben auf irgendwas verlassen noch bei irgend etwas, das du als Funktion übergeben bekommst.

Wenn deine Funktion z.B. einen Parameter X als INT übergeben bekommt der einen Wert von 1-10 haben darf, dann solltest du dich nicht darauf verlassen, dass der Aufrufer sich an die Spielregeln hält, sondern du solltest das prüfen.
Sonst ruft dich einer mit 11 auf und deine Funktion macht irgend einen Blödsinn...
Wenn es mehrere Parameter sind solltest du immer prüfen ob die übergebene Kombination Sinn macht/erlaubt ist...

Wenn du mit Speicherbereichen arbeitest solltest du immer die längen Überprüfen bevor du irgend was damit machst...
Pufferüberläufe sind ja nach wie vor eine verbreitete Sicherheitslücke...

Und wie du schon gesagt hast: Benutzereingaben IMMER prüfen...
sonst bringt dir einer als Eingabe in ein Suchfeld für eine SQL Abfrage " '; drop table xyz...

ahh... und sorry für OT...

[Timbaloo]

Wenn du mit Speicherbereichen arbeitest solltest du immer die längen Überprüfen bevor du irgend was damit machst...
Pufferüberläufe sind ja nach wie vor eine verbreitete Sicherheitslücke...
float sum (float *elements, size_t n_elements)
Viel Glück beim überprüfen ;)

[BigKid]

float sum (float *elements, size_t n_elements)
Viel Glück beim überprüfen ;)
Naja in deinem Beispiel wird auf den Speicher ja nicht schreibend zugegriffen - oder? Aber ja - C und C++ sind da etwas schwach aufgestellt wenn es drum geht die länge von Speicherberichen zu prüfen die man nicht selbst reserviert hat...
Aber das ist keine Entschuldigung das nicht da zu tun wo man es könnte...
Klassiker wäre zB ein strcpy auf einen selbst reservierten oder bekannten Puffer zu benutzen und dann aus Faulheit nicht zu schauen wie lange der (fremde) Quellstring ist...
etc etc etc etc...

[Skysnake]

Der Punkt ist, die Funktion ist ja so definiert, das nur ien Pointer und eben die Länge angegeben ist, und beides wird dir übergeben.

Die Funktion "sum" hat gar keine Chane, zu prüfen, ob das zulässig ist oder nicht, es sei denn in sum wird eine Funktion wiederum aufgerufen, die nachschauen kann, ob die Adressen in zulässigen Bereichen liegen, dafür müsste man aber eben Protokoll führen über alle! Allokationen usw.

Ansonsten würde ich sagen: Schön blöd, wer einem Nutzer eine solche Funktion in die Hand drückt ;)

[iuno]

Man hört gerade gar nichts mehr von Vulkan, von DX12 wird aber 'relativ oft' geschrieben. Wann ist denn die Finale Veröffentlichung zu erwarten? Und gibt es außer der Source inzwischen noch weitere bekannte Engines, die auf Vulkan laufen werden? Ich meine jetzt, wo auch wirklich Spiele kommen sollen, nicht nur Techdemos ;)
Bei Golem stand, dass die Cryengine auf OpenGL & Linux portiert werden soll, leider kein Wort zu Vulkan. Ich denke, wenn jeder erstmal mit DX12 glücklich ist, wird es sehr schwer.

[Unicous]

Die Spec ist noch nicht final, Ende des Jahres wahrscheinlich.

Frostbite wird sicherlich Vulkan bekommen. Vulkan könnte, könnte! deutlich bessere Unterstützung von den Engine-Entwicklern bekommen als "OpenGL" zuvor. Unity wird sicherlich auch dabei sein und idtech denke ich auch.

[Arcanoxer]

Bei der Cryengine gehe ich auch stark von Vulkan support aus.
Früher oder später... Chris Roberts hat es ja schon angesprochen.