Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki |  Impressum

Aktuelle Zeit: Do Mär 28, 2024 13:07

Foren-Übersicht » Programmierung » OpenGL
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 215 Beiträge ]  Gehe zu Seite Vorherige  1 ... 10, 11, 12, 13, 14, 15  Nächste
Autor Nachricht
BeitragVerfasst: Mo Okt 01, 2012 17:24 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Sep 23, 2002 19:27
Beiträge: 5812
Programmiersprache: C++
Kann es sein dass es diese Extension nur in den Headern von NVidia gibt? Unserer basiert auf den von OpenGL bereitgestellten Headern, und dort (gl3.h, glext.h, glxext.h und wglext.h) gibt es die dafür definierten Konstanten nicht?

Wenn ja müsste man überlegen ob wir den NVidia-Header mitaufnehmen.

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


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mo Okt 01, 2012 19:06 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Jan 31, 2007 18:32
Beiträge: 150
Programmiersprache: Pascal
Da ich auf die schnelle keine NVidia Header auftreiben konnte(DevCenter is ja imoment nicht richtig nutzbar), habe ich leider keine ahnung in welchem c# Header diese extension normalerweise auftaucht.

Interessant fand ich gerade diese extension um einen anhaltspunkt zu haben wie viele daten VBO, Texturen, etc. man im speicher hält soweit sie einmal im GPU Speicher sind. Von ATI gibt es dazu noch ein Gegenstück. Inwiefern es nun Sinn macht diese Extension in den Header aufzunehmen, keine Ahnung. Auf der eine Seite sind Vendor spezifische Extensions wesentlich seltener genutzt und es würde eindeutig mehr Aufwand verursachen auf der anderen Seite findet sich aus anderen Headern auch einiges an Extensions die ich der selben Kategorie zuordnen würde.

mfg FrenK


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Fr Okt 26, 2012 13:36 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Jan 31, 2007 18:32
Beiträge: 150
Programmiersprache: Pascal
Warscheinlich verursacht durch diesen Bug fehlen einige functionen für DSA in dem Community Header.

Bei diesen 3 ist es mir zumindest Aufgefallen.
Code:
  1.  
  2. TglEnableVertexArrayEXT = procedure(vaobj: GLuint; array_: GLenum); {$IFDEF DGL_WIN}stdcall; {$ELSE}cdecl; {$ENDIF}
  3. TglEnableVertexArrayAttribEXT = procedure(vaobj: GLuint; index: GLuint); {$IFDEF DGL_WIN}stdcall; {$ELSE}cdecl; {$ENDIF}
  4. TglVertexArrayVertexAttribOffsetEXT = procedure(vaobj: GLuint; buffer: GLuint; index: GLuint; size: GLint; type_: GLenum; normalized: GLboolean; stride: GLsizei; offset: GLintptr); {$IFDEF DGL_WIN}stdcall; {$ELSE}cdecl; {$ENDIF}
  5.  


mfg FrenK


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Patch für dglOpengl.pas
BeitragVerfasst: Mi Nov 28, 2012 12:10 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Hallo,
Ich habe einen kleinen aber wesentlichen Patch:
In der dglOpenGL.pas fehlt beim Funktionstyp "TglXGetVisualFromFBConfig" (ich glaube das ist Zeile 11.188) ein "cdecl". Bitte seid so freundlich und ergänzt das.
Viele Grüße,
Traude


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mi Nov 28, 2012 14:57 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
^ Habe deinen Beitrag mal verschoben damit der Maintainer des Headers (Sascha?) eine Benachrichtigung bekommt :)

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mo Jun 02, 2014 20:31 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Sep 23, 2002 19:27
Beiträge: 5812
Programmiersprache: C++
Ich hab mir heute übrigens mal die neue OpenGL-Debugfunktionalität via GL_ARB_Debug_Output angeschaut. Find ich persönloch ganz gut, und lange überfällig. Leider erst ab OpenGL 4.3 verfügbar, also eher was für moderne OpenGL Hardware.

In meinem GIT-Repository findet sich dazu auch eine passende Delphidemo mit Quellcode.

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


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mo Jun 02, 2014 21:07 
Offline
DGL Member

Registriert: Do Dez 29, 2011 19:40
Beiträge: 421
Wohnort: Deutschland, Bayern
Programmiersprache: C++, C, D, C# VB.Net
Es gibt auch noch "AMD_debug_output" & "KHR_debug" mit ähnlicher Funktionalität.

Ich finde das Feature auch toll, allerdings kann es das nervige klassische Fehlertesten(polling) nicht ersetzen. Es fehlt die Möglichkeit an eine Information zu kommen, wo der Fehler aufgetreten ist. Ein Stack Trace wäre das Beste, aber ich konnte keinen Weg finden, überhaupt irgendwie einen Auslöseort herauszufinden. Das finde ich ein bisschen Schade, weil so muss mah nach wie vor überall auf Fehler testen, was echt nicht mehr zeitgemäß ist.

Vielleicht hat da jemand zufällig eine Lösung? Darf auch ruhig ein platformabhäniger Ansatz sein


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Di Jun 03, 2014 16:37 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Sep 23, 2002 19:27
Beiträge: 5812
Programmiersprache: C++
Die AMD und Khronos-Extensioms sind quasi Vorläufer für die ARB-Funktionalität.

Und an den Callstack kommt man zumindest in Delphi mit der ARB-Debugfunktionalität ohne Probleme. Wenn ich nen Haltepunkt im Callback für das Debugevent setze sehe ich da direkt wo der Event herkommt.

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


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Di Jun 03, 2014 16:45 
Offline
DGL Member

Registriert: Do Dez 29, 2011 19:40
Beiträge: 421
Wohnort: Deutschland, Bayern
Programmiersprache: C++, C, D, C# VB.Net
Interessant. Hängt das vielleicht vom Treiber ab? (Nvidia)
Also bei mir geht der Call Stack vom Debug-Callback aus direkt ins Nirvana einer Treiber DLL.


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mi Jun 04, 2014 20:51 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Sep 23, 2002 19:27
Beiträge: 5812
Programmiersprache: C++
Ich experimentiere übrigens grade mit Compute Shadern und SSBOs, das kommt dabei raus (quasi in Echtzeit erzeugte Kunst) :

http://www.saschawillems.de/images/computeshader_art_02.jpg
http://www.saschawillems.de/images/computeshader_art_06.jpg

(Könnte man sich fast als Gemälde an die Wand hängen ;) )

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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Minor parameter errors
BeitragVerfasst: Do Jul 17, 2014 21:23 
Offline
DGL Member

Registriert: Mi Jul 16, 2014 22:40
Beiträge: 2
Programmiersprache: Lazarus/FPC
Greetings,

Apologies in advance if this is in the wrong place (and for being in English ;) ). If there is a better place to report issues, please direct me to it.

I think I found a few minor type errors in the function declarations in the latest (4.4) version of dglOpenGL.pas:

Line 8515:
Current:
TglGetProgramInfoLog = procedure(programObj: GLHandle; maxLength: glsizei; var length: PGLsizei; infoLog: PGLChar); {$IFDEF DGL_WIN}stdcall; {$ELSE}cdecl; {$ENDIF}
Corrected:
TglGetProgramInfoLog = procedure(programObj: GLHandle; maxLength: glsizei; var length: GLsizei; infoLog: PGLChar); {$IFDEF DGL_WIN}stdcall; {$ELSE}cdecl; {$ENDIF}

Line 8517:
Current:
TglGetShaderInfoLog = procedure(shaderObj: GLHandle; maxLength: glsizei; var length: glint; infoLog: PGLChar); {$IFDEF DGL_WIN}stdcall; {$ELSE}cdecl; {$ENDIF}
Corrected:
TglGetShaderInfoLog = procedure(shaderObj: GLHandle; maxLength: glsizei; var length: GLsizei; infoLog: PGLChar); {$IFDEF DGL_WIN}stdcall; {$ELSE}cdecl; {$ENDIF}

There may be others; I discovered these two when converting a basic shader tutortial.

Also, more of a footnote than anything, while I actually prefer using a var/out parameter for an output variable, rather than the standard OpenGL "pointer to a return value variable", it does remove the ability to pass Nil (NULL in C/C++) to indicate you don't want the value to be returned. Quite a bit of OpenGL code tends to (ab)use this "feature". Something to keep in mind when translating code and headers, I suppose.

Thanks again for such a diligent and useful OP translation of the headers! It is working fine with my translation of SDL 2.0 so far. :)


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Fr Jul 18, 2014 08:09 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Thanks for this submission!

In the first case, it would be required to remove the var qualifier, otherwise we would be passing (at a C level) a **GLsizei, which is obviously wrong. I can see the point of passing NULL, its a documented feature of the function. Same holds for the second fix, which may also be converted to PGLsizei instead.

Note though, if you desperately want to pass NULL, this should be possible by passing PGLSizei(nil)^ (don’t beat me for the exact details of Pascal syntax).

best regards,
Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Fr Jul 18, 2014 17:31 
Offline
DGL Member

Registriert: Mi Jul 16, 2014 22:40
Beiträge: 2
Programmiersprache: Lazarus/FPC
Agreed. Personally, I would just use a dummy variable if I didn't want the returned value; that's how I have always done it using OP. The issue only arises when I am looking at other people's code and see NULL passed to an OpenGL function; I need to check the prototype to make sure if I can pass Nil, or use a dummy instead.

In quite a few SDL2 functions, I used Var parameters when the C prototypes specify pointers, when and where it makes sense to do so, so I am happy to see them used in the OpenGL translation as well. :)

Anyway, back to my testing/engine dev. Thanks again!


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: So Aug 24, 2014 11:49 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Sep 23, 2002 19:27
Beiträge: 5812
Programmiersprache: C++
Im GIT-Repository gibt es jetzt eine dglOpenGL.pas mit OpenGL 4.5 Support : https://bitbucket.org/saschawillems/dglopengl

Aufgrund mangelnder Hardware (bzw. Treiber, ATI brauchen leider immer etwas länger) ist da aber nichts getestet (nur kompiliert und mit 4.4 laufen lassen).

Wer die Hardware hat kann gerne mal testen, und wenn sich dann die Tage nix gravierendes zeigt werd ich die Header auch aktuell stellen.

P.S. : Ein paar Extensions (außerhalb des Kerns) fehlen noch, z.B. die für AMDs GCN, die reich ich dann die Tage nach.

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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: OpenGL 4.5 Header
BeitragVerfasst: Do Sep 03, 2015 13:11 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Sep 23, 2002 19:27
Beiträge: 5812
Programmiersprache: C++
Nach über einem Jahr gibt es mal wieder ein Update.

Der Header wurde v.a. um die vor kurzem angekündigten neuen OpenGL-Extensions erweitert.

Getaggtes Release
GitHub Repository

Hier die Änderungen :

Code:
  1. Added missing constant GL_PRIMITIVE_RESTART_FOR_PATCHES_SUPPORTED (SW)
  2. Added missing constant GL_TEXTURE_BUFFER_BINDING (SW)
  3. Added missing extension GL_NV_conservative_raster (SW)
  4. Added recently announced OpenGL extensions :
  5. Added GL_ARB_ES3_2_compatibility (SW)
  6. Added GL_ARB_fragment_shader_interlock (SW)
  7. Added GL_ARB_gpu_shader_int64 (SW)
  8. Added GL_ARB_parallel_shader_compile (SW)
  9. Added GL_ARB_post_depth_coverage (SW)
  10. Added GL_ARB_sample_locations (SW)
  11. Added GL_ARB_shader_atomic_counter_ops (SW)
  12. Added GL_ARB_shader_ballot (SW)
  13. Added GL_ARB_shader_clock (SW)
  14. Added GL_ARB_shader_viewport_layer_array (SW)
  15. Added GL_ARB_sparse_texture2 (SW)
  16. Added GL_ARB_sparse_texture_clamp (SW)
  17. Added GL_KHR_no_error (SW)
  18. Added GL_NV_conservative_raster_dilate (SW)
  19. Added GL_OVR_multiview (SW)
  20. Added GL_OVR_multiview2 (SW)
  21. Added GL_INTEL_framebuffer_CMAA (SW)


Bei Fehlern entweder hier ne kurze Notiz, oder im Repo ein Issue öffnen.

Da ich inzwischen wieder bei NVidia bin (mit ner ganz neuen GPU), konnte ich zumindest ein paar Sachen probieren, auch wenn es für mich inzwischen ungewohnt ist OpenGL mit Pascal zu nutzen ;)

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


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 215 Beiträge ]  Gehe zu Seite Vorherige  1 ... 10, 11, 12, 13, 14, 15  Nächste
Foren-Übersicht » Programmierung » OpenGL


Wer ist online?

Mitglieder in diesem Forum: Google [Bot] und 28 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
cron
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.080s | 18 Queries | GZIP : On ]