DirectX und OpenGL ziehen nach

Läuft doch fast haargenau ab wie ichs vorhergesagt hab. Die Hardwareentwicklung hat MS eingeholt. Die Hardware hat den Punkt erreicht, andem die Kosten für eine, HAL - unabhängig und deutlich leistungsfähigere Neuentwicklung, im Sub Projektrahmen liegen. Keiner will länger Brute Force HW Layout bauen auch dann nicht, wenn MS die DX Source veröffentlichen würde. Ich denke aber das bleibt länger unter Verschluss als die Akte JFK

Die nächste Schelle für MS liegt schon im Schubfach. AMD und Bluestacks entwickeln zusammen das Android Dual OS, welches AMD auf Windows Systemen bringen will. Damit kann man zwischen beiden OS 'on the fly' switchen aka 'Benutzerwechsel'. Oh man da wird sich MS freuen, wenn das virtuelle Android plötzlich mal schneller, wie das Windows ist. Ich hab das Bluestacks Beta und das ist nicht nur verdammt schnell, sonder auch noch hoch kompatibel. Irgenwie echt hart Android dem Windows einfach mal so vor die Nase gesetzt..lol
 
Wenn du mir das codetechnisch beweisen kannst, dann glaube ich dir. Und drei verschiedene APIs wäre der größte Scheiß. OpenGL wäre eine Alternative.
Ich für meinen Tel würde 3 relativ ähnliche Low level API's der DX API Vorziehen.

Zu OpenGL sage ich aufgrund von Befangenheit (dort arbeite ich mich ua grad rein) nichts, wäre aber wenn es schneller und Multithreadingfähig wird definitiv eine brauchbare Alternative.
 
Ich für meinen Tel würde 3 relativ ähnliche Low level API's der DX API Vorziehen.

Zu OpenGL sage ich aufgrund von Befangenheit (dort arbeite ich mich ua grad rein) nichts, wäre aber wenn es schneller und Multithreadingfähig wird definitiv eine brauchbare Alternative.

Mit modernem OpenGL limitiert sowieso zuerst die Hardware. Das sagt AMDs OpenGL Fritze selbst.

Bildschirmfoto vom 2014-02-27 14:48:52.png

Das gleiche sagt auch John Carmack.

carmack.png

Da braucht man nix mehr schneller machen. Eine eigene Marke wie Mantle ist halt ne super Marketingmaschine.
 
Ja total Marketing, OGL hat nicht einmal Multi-Threading in Angriff genommen, bei DX ist es broken by design und beim Steam Dev Day gab es eine Menge Vorträge über Speed und Probleme.
Keine der APIs hat explicit memory control etc.
 
Natürlich limitiert zuerst die HW:lol:
Nur in dem Fall wohl eher die CPU als die GPU.

Diese aussage klingt in meinen Ohren sowieso nach heisser Luft: wieso wird dann nicht seit Jahren OGL anstelle von DX verwendet? wenn dich die API schon so unglaublich gut ist?

Von meinem Multithreading Problem mal ganz zu schweigen. Und wie der name erahnen lässt befasse ich mich schon schon gute 5 Jahre mit dem Thema.
 
Glaube Leute bilden sich auf Multi-Threading viel zu sehr etwas ein. Was bringt's wenn man dadurch nur Race Bedingungen schaft und die meiste Zeit dann damit verplempert die Sachen wieder zu synchronisieren? Ist halt ein tollen Buzzword Multi-Threading.
 
Glaube Leute bilden sich auf Multi-Threading viel zu sehr etwas ein. Was bringt's wenn man dadurch nur Race Bedingungen schaft und die meiste Zeit dann damit verplempert die Sachen wieder zu synchronisieren? Ist halt ein tollen Buzzword Multi-Threading.
Dann hast du Multithreading nicht richtig verstanden und/oder komplett Falsch angewandt. Du musst nicht aufgaben verteilen die dauernd zusammengeführt werden müssen, du musst aufgaben Verteilen die möglichst unabhängig voneinander sind.

Kennst du das 'Problem der Spaghetti essenden Philosophen'?
Ich weiss nicht wie viel du davon verstehst, aber viele Entwickler haben schon mit dieser simplen Aufgabenstellung massive Probleme. Eben weil Sie Multithreading nicht genügend verstehen.

ja, auf solche Probleme lache ich mir einen runter, sowas empfinde ich als leicht zu lösen. Multithreadingfähig wohlgemerkt.
 
Genau Multi-Threading is das Allheilmittel. ;)

Und warum nutzen die Leute eigentlich seit Jahren D3D, wenn es so eine schlimme API ist mit soviel Overhead? ;)
 
Genau Multi-Threading is das Allheilmittel. ;)

Und warum nutzen die Leute eigentlich seit Jahren D3D, wenn es so eine schlimme API ist mit soviel Overhead? ;)
Vor wenigen Jahren wurde noch oft nur DX9 verwendet, vermutlich weil die API so toll ist oder?
Es geht doch immer irgendwo um Spieler-Volumen, Zeit und Kosten etc.

Darüber hinaus ist es ja nicht nur das Multi-Threading, wo Mantle Fortschritte zeigt.
 
I-Novae Studios: Why OpenGL Probably isn't the Graphics API of the Future and I Hope it Dies

Habe ich schon mal irgendwo gepostet. Auch OpenGl ist anscheinend nicht das gelbe vom Ei.

Und selbst das ist schon pauschalisierende Meinungsmache (allein bei dem Punkt, dass Microsoft "fast immer ganz ganz ganz tolle Doku hat" bekomm ich die Krise...). Letztenendes werden auch Direct3d bzw. Opengl bzw. irgendsowas-neues-in-der-Richtung überleben. Nicht jeder/jedes Spiel braucht "Low Level" (was auch immer das heißen mag, wie Low Level Mantle ist sieht man ja noch nicht wirklich) Zugriff...
 
Naja jeder hat seine eigene Meinung... Zum Glück. Ich kann leider die Richtigkeit des Textes nicht wirklich überprüfen da ich überhaupt nichts mit den beiden APIs zu tun haben. Aber vor allem der Punkt zur Abwärtskompatibilität scheint mir plausible. Wenn man eine solche gewährleisten muss, ist es schwer größere Umstrukturierungen zu machen. Sieht man schön an Java. Der Sprung von Jdk 5 zu 6 hat so manchen s*itstorm ausgelöst. Zum Punkt mit dem low level. Mantle bietet anscheinend schon "bessere" Möglichkeiten auf der Hardware der Graka zu arbeiten als die anderen beiden. Das wurde auch schon von dem ein oder anderen Entwickler geschrieben.

Ob man sich jetzt an ein Statement wie "fast immer ganz ganz tolle Doku" aufhängen muss bezweifele ich. C# und auch die Win Api hat eine ganz gute (im Vergleich zu Java vielleicht nicht ganz so gut).
 
Für mich bleibt das einfach skuril das AMD mit mantle Geld und Ressourcen geopfert hat damit nun nvidia Karten die effizienten Nutznießer sind.
Ich freu mich aber trotzdem das alle mehr potentielle Leistung erhalten.

Mfg Drebbin
 
Natürlich limitiert zuerst die HW:lol:
Nur in dem Fall wohl eher die CPU als die GPU.

Diese aussage klingt in meinen Ohren sowieso nach heisser Luft: wieso wird dann nicht seit Jahren OGL anstelle von DX verwendet? wenn dich die API schon so unglaublich gut ist?

Von meinem Multithreading Problem mal ganz zu schweigen. Und wie der name erahnen lässt befasse ich mich schon schon gute 5 Jahre mit dem Thema.

Seit 5 Jahren schon ohne zu wissen warum. :wow:
Grundsätzlich ists bereits mit einem Satz erklährt. Musst halt einfach genau in die Richtung weiter denken, dann siehst die Anworten sind nicht deine Fragen.

OGL vs. DX ist grob gesagt,

Funktionen sind die unbekannte X, durch die HW definierbar vs.
Beschriebene Funktionen aus Konstanten und Parametern, strikt HW definierend.
 
Ja total Marketing, OGL hat nicht einmal Multi-Threading in Angriff genommen, bei DX ist es broken by design und beim Steam Dev Day gab es eine Menge Vorträge über Speed und Probleme.
Naja, den Bedarf an Multithreading kann man bei OGL (und D3D und jedem ähnlichen API) dadurch umgehen, dass man den OGL-Thread wirklich nur über eine vollständig vorbereitete Struktur iterieren und Draw Calls machen lässt. Die kann man problemlos in mehreren Threads erzeugen. Buffer-Objekte kann man auch mit einem zusätzlichen Thread mit Daten aus dem Speicher befüllen, weil dafür keine GL-Calls notwendig sind (mehr als ein Thread ist dafür aber nicht sinnvoll - Speicherbandbreitenlimit).

Also bei Multithreading sehe ich nicht den größten Vorteil von Mantle. Der dürfte eher irgendwo bei ease of use und einer weit weniger komplexen State Machine liegen (irgendjemand hier im Forum hatte in einem Battlefield 4-Thread mal die Liste aller dort genutzten Mantle-Funktionen gepostet - vergleicht das mal mit GL), und als Low Level-API dürfte es dem Entwickler auch einen größeren Teil der Grafikspeicherverwaltung überlassen.

OpenGL 4.4 + Sparse Array Textures + Bindless Textures gehen zwar in eine ähnliche Richtung, aber die letzten beiden Sachen sind noch nicht einmal im Core-Profile und wirklich schön ist das API imho schon lange nicht mehr. Dazu kommt, dass AMD immer noch bei GL 4.3 herumgurkt.
 
Zurück