MinGW64 und GLES2 Emulation?

[snoob741]

In meinem Projekt unterstüzte ich seit kurzem den c++11 Standard. Daher musste ich meine MinGW Umgebung zwangsweise auf die 64bit Version umstellen. Hierfür benutze ich MinGW-builds mit dem GCC 4.8. Soweit so gut, ich kann auch alles bauen und kompilieren. Nun kämpfe ich jedoch seit einigen Tagen mit der GLES2 Emulation, die bekomme ich nicht zum Laufen.

Ich habe mir die aktuelle Version von PVRFrame besorgt um einen 64bit GLES v2 und v3 Emulator zu bekommen. Und bei mir in die MinGW Umgebung integriert. Kompilieren kann ich meinen GLES2 Code auch, nur bekomme ich das ganze nicht zum Laufen, wenn ich meine Applikation Starte erhalte ich beim Erzeugen des VBO's bereits ein Exception:

[Fri May 17 11:09:15 2013]: OpenGLES2.0 demo v1.0
[Fri May 17 11:09:15 2013]: EGL version: 1.3
[Fri May 17 11:09:15 2013]: Driver vendor: Imagination Technologies (Host: (null))
[Fri May 17 11:09:15 2013]: OpenGL version: OpenGL ES 2.0 (Host: (null))
[Fri May 17 11:09:15 2013]: Graphics card : PVRVFrame 9.4 - Host (OpenGL) (Host: (null)) (SDK Build: 3.0@2224087)
[Fri May 17 11:09:15 2013]: Supported OpenGL ES extensions :
-GL_OES_byte_coordinates
-GL_OES_fixed_point
-GL_OES_query_matrix
-GL_OES_single_precision
-GL_OES_matrix_get
-GL_OES_read_format
-GL_IMG_read_format
-GL_OES_point_sprite
-GL_OES_query_matrix
-GL_OES_texture_env_crossbar
-GL_OES_texture_mirrored_repeat
-GL_OES_blend_subtract
-GL_OES_blend_func_separate
-GL_OES_blend_equation_separate
-GL_OES_stencil_wrap
-GL_OES_extended_matrix_palette
-GL_OES_compressed_ETC1_RGB8_texture
-GL_OES_compressed_paletted_texture
-GL_OES_depth_texture
-GL_OES_required_internalformat
-GL_EXT_discard_framebuffer
-GL_OES_texture_cube_map
-GL_OES_fragment_precision_high
-GL_OES_element_index_uint
-GL_IMG_texture_compression_pvrtc
-GL_OES_mapbuffer
-GL_EXT_multi_draw_arrays
-GL_OES_standard_drivatives

[Fri May 17 11:09:15 2013]: EGL window created.
[Fri May 17 11:09:15 2013]: EGL windows surface created.
[Fri May 17 11:09:15 2013]: EGL render context created.

Try to generate buffer.
(Error) The following error occurred in glGenBuffers: (502) GL_INVALID_OPERATION
Buffer generated

Hier wurde nichts besonderes gemacht:

Code: Alles auswählen

    GLuint vertexBuffer;
    glGenBuffers (1, &vertexBuffer);

OpenGLES Extensions werden initialisiert. EGL und Display Objekte auch vorher erfolgreich erzeugt, beim Aufruf von
Standard OpenGL Extensions kommt es dann jedoch zum Crash, gleiches übrigens auch bei der Shadererzeugung.

Der (GLES2) Code sollte eigentlich i.O. sein, denn mit dem Android ADT bekomme ich den selbigen Code zum Laufen.
Hat hier jemand Efahrung und kann mir ggfs. weiterhelfen? Bzw. nutzt Ihr einen anderen Emulator?

Danke.

[Schrompf]

Zum eigentlichen Problem kann ich Dir nichts sagen, aber ich frage mich: warum sollte man für C++11 auf 64Bit umstellen müssen? Ist das irgendein MinGW-Bug? Normalerweise haben die beiden Themen nämlich nichts miteinander zu tun.

[snoob741]

So könnte man es nennen ;) Für MinGW32 gibt es leider keinen Support für die POSIX basierten std::threads die es seit c++11 gibt. Um thread safe Singletons zu haben, setze ich diese ein. Nur MinGW64 hat eine Adaption für POSIS threads als Experimentalumgebung...

Boost hatte ich erst raus geschmissen um die Abhängigkeiten endlich los zu werden und die Android Entwicklung zu vereinfachen. Die einzige Alternative, währen die Boost threads gewesen. Viele Boost Mechanismen lassen sich ja 1:1 auf den c++11 Standard umstellen, nur hier geht das nicht. Und zurück zu Boost wollte ich nicht. Daher der Wechsel.

[Florian Keßeler]

Schrompf: Darüber bin ich auch schon gestolpert, als ich ein mittelgroßes C++11 Projekt von Linux nach Windows portieren wollte. Ich dachte, nimmste einfach MinGW 4.7.2, gleicher Compiler, wird schon passen. Ist aber nicht so, der C++11 Support bei MinGW hinkt um Jahre hinterher. Keine Ahnung wie es bei mingw-builds ist. MinGW64 ist wohl ein Fork von MinGW32, bei dem es bessere läuft.

Aber genau aus diesem Grund hab ich vorrübergehend sämtliche Portierungsarbeiten an meinem Projekt eingestellt, bis sich das Problem von selbst löst...

[kimmi]

Hast du das Ganze schon mal mit der Angle-Lib versucht, die du zuvor mit mingw 64bit übersetzt hast? Mich düngt, dass da irgendwas mit der Binärkompatibilät rumspinnt. Dementsprechend könntest du das Ganze mittels Angle-Lib selber bauen und dann mal schauen, was geht und was nicht.

Gruß Kimmi

[snoob741]

Danke für den Tipp mit der Angle-Lib die kannte ich noch nicht. Werde ich mal ausprobieren.

[snoob741]

Auf Euer raten hin und nachdem ich vom PVRFrame Team die offizielle info habe, dass die Libs nicht MinGW64 kompatibel sind, versuche ich nun seit einer Weile das Angleprojekt als Emulator für meine MinGW64 Umgebung aufzusetzen. Leider ist das gesamte Projekt ausschließlich für das Visual Studio designed womit ich mich überhaupt nicht auskenne. Ich habe zwar inzwischen nach vielem hin und her VS2012 Express installieren können und kann auch die libs als x64 Projekt bauen, nur sind diese inkompatiebel zum MinGW64 Linker.

Nun versuche ich mit CMake die einzelnen Module des Angle-lib Projektes zu bauen. Verliere mich jedoch immer wieder in endlosen Abhängigkeiten, die ich irgendwie nicht aufgelöst bekomme, bzw. suche ich mich in den vielen VS Menüs dusselig :oops: Hat jemand von Euch Erfahrung mit dem Bau des Angleprojektes unter MinGW oder Cygwin und kann mir näheres zu den Abhängikeiten sagen. Oder vielleicht einen Tipp geben wo ich genau im VS schauen muss, damit ich finde was ich suche?

[Sternmull]

VS2012 hab ich noch nicht benutzt, aber in VS2008 und VS2010 geht das so: Wenn man genau wissen will mit welchen Einstellungen eine Datei gebaut wird, kann man sich die betreffende "Befehlszeile" angucken. z.B. Rechtsklick auf ein Projekt, Eigenschaften, C/C++, Befehlszeile. Hier kann man sich die /I und /D Optionen usw. abgucken. Gleiches gibts auch für den Linker. Für einzelne Dateien kann der Compiler auch eine abweichende Kommandozeile haben, das sieht man dann in den Dateieigenschaften.

Um eine Übersicht zu bekommen ob einzelne Dateien separat konfiguriert wurden, würde ich aber wahrscheinlich die Projektdatei mit einem Textedior öffnen... da dürfte man den Überblick schneller erlangen als wenn man sich den Eigenschaften-Dialog für alle Dateien angucket. Aber in den meisten Projekten ist das nicht notwendig.

[snoob741]

Danke für die gute Beschreibung werde nach Feierabend mal schauen. Aber evtl. kann ich mir das auch sparen, habe hier etwas gefunden, was mir evtl. ermöglicht auch die VS2012 libs für MinGW64 zu übersetzen um die Linker Inkompatibilität zu beheben:

http://sourceforge.net/projects/mingw-w ... ic/3882579

[snoob741]

Hmm a hab ich mich irgendwie zu früh gefreut. Der x64 Build mit dem Visual Studio klappt doch nicht. Ich kann zwar ohne Probleme für die 32bit Platform das Angleproject bauen, aber sobald ich auf x64 Platform builds umstelle, geht der Build in die Hose:

error LNK1104: File "C:\angleproject\src\compiler\x64\Debug\BuiltInFunctionEmulator.obj" could not opened. C:\angleproject\src\libGLESv2\LINK libGLESv2

Die Fehlermeldung ist korrekt. Die Ojbektdatei existiert nicht. Ich habe inzwischen herausgefunden, dass die vermisste Datei Bestandeilt des indirekt referenzierten translator_common Subprojectes ist das selbst vom translator_hlsl Projekt referenziert wird, welches zu libGLESv2 Projekt eine Abhängigkeit hat. Und jetzt kommt der kuriose Part:

1. Baue ich die translator Projekte einzeln als x64 build, dann werden zwar die libs erstellt, aber keine Objektdateien unter x64/Debug.
2. Baue ich die Projekte als x86 build dann werden die .obj Dateien unter Debug/common und Debug/hlsl abgelegt und unter x64/Debug (gemischt, nicht nach Verzeichnissen getrennt)
3. Baue ich anschließend das libGLESv2 Projekt, dann werden die .obj Dateien wieder gelöscht und sind weg ...

Da ich mich mit dem Visual Studio nicht auskenne habe ich keinen Blassen was hier abgeht. Irgendwie scheint er Murx bei der Konfiguration zu machen. Verstehe aber nicht wo und die Menüs sind wie Sternmull schon geschrieben hat nicht grad übersichtlich ... Habe eher das Gefühl das ich mich in unendlichen Weiten verliere :roll:

Ich VS Dau bin Euch dankbar für jede Hilfe.