OpenGL ES Spezifikation ist fertig

[Demirug]

Passend zum Release (http://www.forum-3dcenter.net/vbulletin/showthread.php?s=&threadid=84867) des Acceleon (http://www.acceleon.com/) der Bitboys gibt es nun auch die Spezifikation von OpenGL ES (http://www.khronos.org/opengles/spec.html).

OpenGL ES ist eine OpenGL Variante für Mobile Geräte mit 3D Beschleunigern.

[Ailuros]

Passend vielleicht schon, nur haben BB nur ein einziges meeting fuer OGL ES besucht; die Finalisierung wurde auschliesslich von ImgTec und ARM in einem "one to one" meeting ausgetragen.

Uebrigens:

http://www.arm.com/news/MIPI290703

[aths]

Kann man OpenGL ES auch auf der PC-Plattform verwenden?

edit: Ich lese gerade, Display Lists würden nicht unterstützt. Heißt dass, dass nur der "Sofort-Render-Modus" funzt? Ist dieser nicht vergleichsweise lahm? Interessant finde ich übrigens das 32-Bit-Fixpoint-Format :) FPU-Logik scheint es für Handhelds noch nicht zu geben.

[Demirug]

Original geschrieben von Ailuros
Passend vielleicht schon, nur haben BB nur ein einziges meeting fuer OGL ES besucht; die Finalisierung wurde auschliesslich von ImgTec und ARM in einem "one to one" meeting ausgetragen.

Uebrigens:

http://www.arm.com/news/MIPI290703

Ich schrieb passend weil der Acceleon ja OGL ES unterstützt.

[Demirug]

Original geschrieben von aths
Kann man OpenGL ES auch auf der PC-Plattform verwenden?

edit: Ich lese gerade, Display Lists würden nicht unterstützt. Heißt dass, dass nur der "Sofort-Render-Modus" funzt? Ist dieser nicht vergleichsweise lahm? Interessant finde ich übrigens das 32-Bit-Fixpoint-Format :) FPU-Logik scheint es für Handhelds noch nicht zu geben.

Bei OpenGL ES wird nur über VertexArrays gerendert. Den "Sofort-Render-Modus" gibt es dort nicht.

Da OpenGL ES ja nur ein Subset vom "normalen" OpenGL darstellt ist es im Prinzip kein Problem. Kritisch sind nur die zusätzlichen Erweiterungen.

[Ailuros]

Original geschrieben von Demirug
Ich schrieb passend weil der Acceleon ja OGL ES unterstützt.

Mal OGL ES zur Seite, der einzige Grund warum ich was gegen BB Konzepte habe, ist dass sie nie vorhatten und vorhaben ihre eigene Software zu schreiben.

Selbst wenn sie je ein Produkt veroeffentlicht haetten, haette ich es mir gerne persoenlich angeschaut, aber bei Klang von 3rd party drivers werd ich schon misstrauisch. Bei embedded devices ist es IMO noch schlimmer.

Gib mir die best Hartware der Welt, wenn der Treiber nichts wert ist kann ich nicht viel damit anfangen...ooops warte mal sag ich das gerade einem Entwickler? :D

Nun gut zugegeben es gibt keine Garantie dass die Treiber auch mies sein muessen, aber selbst wenn ich voreingenommen klinge ist es mir lieber wenn der Hartwaren-Entwickler sich auf fuer die Software kuemmert und den Support des ganzen.

[Ailuros]

Mal ne andere Frage was Acceleon betrifft: da nichts bis jetzt aufgefuehrt wurde ueber T&L/VS oder Geometrie-Leistung ***, sind die Bezier patches auf software basierend?

***Bei Inquirer soll ein BB Offizieller angegeben haben dass der chip sehr wenig Strom verbraucht und schneller als eine PS1 sein soll. >500k polys/sec? *raeusper*

[Demirug]

ja, 3dparty Treiber können durchaus kritisch das mit dem embedded devices ist inzwischen in der Regel nicht mehr ganz so schlimm. Dank Flashspeicher kann man da ja inzwischen auch nachträglich updaten.

Das BB die Treiber nicht selbst schreiben wollen dürfte wohl daher kommen das sie mit der Vielzahl von möglichen Platformen einfach überfordert sind.

[Demirug]

Original geschrieben von Ailuros
Mal ne andere Frage was Acceleon betrifft: da nichts bis jetzt aufgefuehrt wurde ueber T&L/VS oder Geometrie-Leistung ***, sind die Bezier patches auf software basierend?

***Bei Inquirer soll ein BB Offizieller angegeben haben dass der chip sehr wenig Strom verbraucht und schneller als eine PS1 sein soll. >500k polys/sec? *raeusper*

Darüber weiss ich absolute nichts. Was ich allerdings merkwürdig finde ist das auch der Grafikcore der PSP Bezier patches unterstützen soll. Neu ein Zufall?

[Ailuros]

Das BB die Treiber nicht selbst schreiben wollen dürfte wohl daher kommen das sie mit der Vielzahl von möglichen Platformen einfach überfordert sind.

ROFL ;D

Darüber weiss ich absolute nichts. Was ich allerdings merkwürdig finde ist das auch der Grafikcore der PSP Bezier patches unterstützen soll. Neu ein Zufall?

Ich bezweifle dass es ein Zufall ist. Wie dem auch sei warte ich erstmal ab bis Stromverbrauch und andere Kleinigkeiten veroeffentlicht werden. Eine wage Angabe ueber Leistung und nur eine Behauptung von niedrigem Stromverbrauch sagt mir momentan nicht viel.

Bei sehr kleinem Stromverbrauch koennten sie eventuell sogar einen guten Erfolg landen. Man darf auch nicht so streng sein; es ist der erste chip der das Potenzial hat nicht als Vapourware auf einem Regal zu landen.

[Achill]

Die OpenGL ML Spec. sind auch da, aber seit dem 28.7.03 (laut seite) liegt dort auch eine SDK für Win32 und Linux...

Wolltes nur anmerken, weil ebend gesehen ;)

[zeckensack]

Original geschrieben von aths
Kann man OpenGL ES auch auf der PC-Plattform verwenden?OpenGL ES ist ein reines Subset. Um mit dieser Philosophie nicht brechen zu müssen, wurden extra Features in das 'große' OpenGL eingefügt. Wie eben der fixed-Datentyp. Diesen wird es ergo - zumindest theoretisch - auch auf der PC-Plattform geben :)
edit: Ich lese gerade, Display Lists würden nicht unterstützt. Heißt dass, dass nur der "Sofort-Render-Modus" funzt? Ist dieser nicht vergleichsweise lahm?[/SIZE]DLs für Geometrie sind erstmal statische VAs, die nie mehr geändert werden können. Der beschränkte Einsatzbereich macht sie nicht besonders attraktiv für Embedded-Anwendungen, zumal dort der Grafikchip idR über die gleiche Bandbreite verfügt wie der Host-Prozessor. Geometrie-DLs wären also nichtmal schneller als 'billigste' vertex arrays im System-Speicher. Wenn's mal mehr sein soll, kann man statt Geometrie-DLs auch VBO benutzen, das kann genau das gleiche, nur noch mehr ;)

DLs machen btw auch die Treiber um ein vielfaches komplizierter, weil man damit eben nicht nur Geometrie, sondern für jeden beliebigen 'server state' verkapseln kann. Unnötig komplexe (=große) Treiber sind für das angedachte Einsatzgebiet natürlich nicht besonders erstrebenswert.