Rough fix: (breaks glugetstring used in ReadCoreVersion, but fixes loading function and so glsl)


somehow using dlsym before the glx method initializes some functions wrongly ? ...

_________________
http://3das.noeska.com - create adventure games without programming

Noeska: The behavior in the documents sound "a bit" strange for me. Not only a bit. And i dont really understand what they want to do. In your rough fix you only load glXGetProcAddress with dlsym and all other methods with glXGetProcAddress. Right? If it's help i will change it in the header. But i can't really test it. Linux isn't my kind of system.

This methode is correct because the specs of ATI say that you have to use glXGetProcAddress to get function pointer of the OpenGL ARB, Ext and Core functions of OpenGL. If i remember right, then it's a rule of the X11 server. There are left some months,years that i solved the problem on my framework but i remember that i wrote a post in the forum.
http://www.opengl.org/sdk/docs/man/xhtml/glXGetProcAddress.xml your code will be linked with the opengl1.2 library and at runtime it will use the nv or ati driver which have a other function set.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Tak. Die Methode wird ja verwendet. Nur eben eher wie das im Windows der Fall ist. Also zu erst wird versucht es direkt aus der DLL zu laden und sollte das schief gehen dann wird glXGetProcAddress benutzt. Aber so wie ich das Dokument verstanden habe liefert dlsym auf einem "normalem" System immer einen Pointer. Auch wenn der totaler schrott ist. Solch einen Sachverhalt hatte ich deinen Beiträgen nicht gelesen. Zu mindest sofern ich das noch richtig in Erinnerung habe!

dlsym liefert auf alle ogl befehle 0 zurück, wenn sie nicht teil des opengl1.2 core sind.
Deswegen tut man als erstes mit dlsym sich glXGetProcAddress holen und dann mit dieser alle opengl befehle suchen.
NVidia hält sich z.B. nicht ganz an die specs und da bekommt man auch mit dlsym einige funktionen wärend sich ATI penibel dran hält und somit diese Reihenfolge dringend notwendig macht.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Dann frage ich mich gerade warum hier eine Änderung notwendig sein soll? Denn genau so wird aktuell gearbeitet. In InitOpenGL werden die Kern + weitere Funktionen geladen. Darunter auch glXGetProcAddress und glXGetProcAddressARB. Und ab dem Zeitpunkt wo die beiden Funktionen geladen wurden werden die auch zum Laden von allen anderen Funktionen berücksichtig. Nur mit dem Unterschied das zu erst immer dlsym versucht wird. Sollte dieses null zurück geben wird glxGetProcAddress benutzt. Sollte also funktionen? Tut es aber scheinbar nicht. Oder ich verstehe dich schlicht und einfach falsch.

Ok these are the results of calling dlsym vs glxGetProcAddress:


Notice that dlsym on the host linux also gives the same as glxGetProcAddres but it should have give 0 and let glxGetProcAddress do the work.
Also notice that dlsym and glxGetProcAddress on the virtualbox client give 2 different addresses but neither being 0 . And only the one retrieved via glxGetProcAddress works.

That is quite possible as tak2004 earlier stated and refered to:
http://www.opengl.org/sdk/docs/man/xhtml/glXGetProcAddress.xml


So on my host pc the runtime equals the link library, but it does not do that on my virtual box client pc. And worse the link library does not return 0 on the dlsym call on the virtualbox client pc.

On windows things may behave differently as that does not use glxGetProcAddress.

Now it would be nice if glxGetProcAddress returns 0 if a fuction is not availeable but i am told that that is not always the case:
http://dri.freedesktop.org/wiki/glXGetProcAddressNeverReturnsNULL

PS take a peek at how glew implements things. I believe they only use glxGetProcAddress?

PS2 i am still searching to get glu things to work again as they cannot be loaded using glxGetProcAddress as stated in the docs but yet are not give 0 as an address ...


Updated rough fix:

_________________
http://3das.noeska.com - create adventure games without programming

Hmm, but this is a bug of the virtual box isn't it? I am here on Linux Ubuntu with Free Pascal 2.2.4 (this is not the latest version) and my graphic card has OpenGL Version 2.1.

I just tested what dglOpengl.pas reads from the 3.0 procedures: it always returns >>NIL<<. I use native pascal code, NOT a virtual box. So, what about "glXGetProcAddressNeverReturnsNULL" ?.

It does not make any sense to me if glXGetProcAddress returned a fake pointer if it was not successful.

Traude: If i understand this right it's only pure luck that it works. Because the most functions depends on an active context. But it seems that they try to implement of querying function if no context is avail. So they "cache" the functions/names and simulate them with pseudo functions. On calling this functions they try to load the real functions. Virtualbox implement this strictly from the definition while the drivers are much nicer.

Noeska: Thanks for your advice. You are right. The best way is to have an look at the glew framework. Only to prevent other presents from X-Systems.

My fix will look an bit else. Inside InitOpenGL the first loaded function has to be glxGetProcAddress and glxGetProcAddressARB. Inside dglGetProcAddress the function will be loaded with glxGetProcAddress if it exists. Else with dlsym. So only glxGetProc* will be loaded with dlsym all other with glxgetProc*. For glu dglGetProcAddress needs an new parameter (ForceDLSysm) (only for linux and optional (default = false)). This parameter must be set for all glu functions. So you can prevent parsing and testing the name. Because the namecheck will fail for glUnmapBuffer, glUseProgram, glUniform*.

btw: this behavior inside linux is really crap.

Schau ich mir an wenn ich nachher daheim bin. Was mich etwas wundert ist dein Pixelformat. Ist das überhaupt gültig? 24 Bit Farbe ist OK, aber 1 Bit Alpha und 32 Bit Tiefe? I.d.R. hat man auf aktuellen Karten 24 Bit Farbe, + 8 Bit Alpha und dann 24 Bit Tiefe + 8 Bit Stencil (DWord-Ausrichtung). Und das PFD_OVERLAY_PLANE sieht mir da auch verdächtig aus, oder hast du ne spezielle Karte die OpenGL auf nem Overlay unterstützt? Normal wäre da PFD_MAIN_PLANE.

Kannst du es mal mit einem normalen (Wie oben beschriebenem) Pixelformat und PFD_MAIN_PLANE probieren? Wie gesagt nutzen diverse Leute (inkl. mir) unseren Header mit MSAA und das funktioniert tadellos.

Oder schau dir mal die Funktion CreateRenderingContext in unserem Header an, ich seh da einige Unterschiede zu der Art und Weise wie du da was erstellst (z.B. PIXELFORMATDESCRIPTOR ohne T, etc.), und kopier doch mal den Kram da raus, pass ihn an und teste dann mal so. Am Header selbst sollte es nicht liegen.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Konnte aus deinem Posting leider nicht rauslesen ob es jetzt geht oder nicht? War mein letztes Posting hilfreich und klappts jetzt, oder geht MSAA immernoch nicht?

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

glGetString(GL_EXTENSION) ist deprecated in 3.0 und in 3.1 raus genommen worden genauere infos hier.

So hab ichs fürs erste gelöst :


mfg FrenK

Danke für den Hinweis, hab mir deinen Link angesehen und werd schauen dass ich es so auch in unserem Header umsetze.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Erstmal großen Respekt für den Aufwand und vielen Dank für einen tollen Header.
Mir ist aufgefallen dass ein Teil der EXT_direct_state_access-Extension fehlt, nämlich sämtliche Befehle die sich um VertexArrayObjects drehen.

MfG
breakdancingYoda

_________________
The force, strong it is in OpenGL.

Extension GL_NVX_gpu_memory_info fehlt.

mfg FrenK