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

Aktuelle Zeit: Do Mär 28, 2024 19:20

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



Ein neues Thema erstellen Auf das Thema antworten  [ 18 Beiträge ]  Gehe zu Seite 1, 2  Nächste
Autor Nachricht
BeitragVerfasst: Do Jan 22, 2015 12:18 
Offline
DGL Member

Registriert: Di Aug 23, 2005 09:15
Beiträge: 31
Programmiersprache: FPC/Delphi XE3
(Hintergrund: ich arbeite an ein Updaten von ein Metafile ähnliches Overlay über ein Kamera Bild nach modernere GL. Es ist jetzt meistens schon alles mit arbbuffer und drawarrayarb, aber in Opengl 2 Zeiten gemacht) Es gibt ein Bild (=Texture), Rechtecke (gefüllt oder leer (nur das Frame)), Zirkel, Linien und Text )

Ich zeichne heute Rechtecken mit

Code:
  1.  
  2.     glBindBufferARB(GL_ARRAY_BUFFER_ARB, FRectVBO);
  3.     glVertexPointer(2, GL_FLOAT, 0, nil);
  4.     glBindBufferARB(GL_ARRAY_BUFFER_ARB, FRectCBO);
  5.     glColorPointer(4, GL_UNSIGNED_BYTE, 0, nil);
  6.     glDrawArrays(GL_QUADS, 0, ovldata.FRectCount * 4);
  7.  


Aber GL_QUADS ist deprecated seit OpenGL 3.1

Es können wirklich eine Menge Quads sein (50k oder 100k+ im schlechtesten Fall), und weil es
eine Kamera Anwendung, sind jedes Image alle Daten neu -> also alles wird immer nach der Karte geladen -> ich möchte gern das Format kompakt halten (jetzt 4 2D Vertices pro Rechteck + 4 Bytes Farbe Informationen)

Die meisten Tutorials sagen man soll DrawArrays mit GL_QUAD durch glDrawElements mit indizierter GL_TRIANGLE ersetzen, aber heißt das auch das man die Indizien pro Objekt wiederholen muss? (mit 6 ushort Indizen pro Rechtecke würde das eine Menge langsamer)

Fragen

(1) Weißt jemand ob man das mit einem Satz Indizien machen kan? Hat jemand ein Beispiel mehrere (indizierter) Objekte in einer glDrawelements Anruf zu zeichnen?

(1b)Oder kann ich sollte ich es mehr in der Direktion Geometrischen Shader suchen ? Damit sollte man auch mit nur 4 Koordinaten ein Rechtecke zeichnen müssen). Man sagt Geometrie Shader sind langsam, aber wie langsam? :_)

(2) würde es möglich gefüllte und leere Rechtecke mit nur einen Array zu beschreiben (und also in einen einzigen gldraw* zu Zeichnen), mit einem zusätzlichen Byte Metadata ( Ich nehme an das würde auch mehr in der Richtung Geometrie Shader gehen)


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Do Jan 22, 2015 13:20 
Offline
DGL Member

Registriert: Do Dez 29, 2011 19:40
Beiträge: 421
Wohnort: Deutschland, Bayern
Programmiersprache: C++, C, D, C# VB.Net
1) Binde einfach einen Index Buffer der nacheinander deine Indices als Integeer enthält.
Zeichnen kannst du dann ganz einfach mit "glDrawElements"

1b) Ich würde in dem Fall auf den Geometry Shader verzichten. Das es keine Quads mehr gibt ist schade - aber nicht wirklich tragisch: 6 Indices statt 4 sind jetzt nicht ein riesen Problem. Ein Geometry Shader würde ich als normalerweise ieffizienter einstufen, aber mir Sicherheit weiß man das natürlich immer erst wenn man es ausprobiert hat.
(Nebenbei: Falls du trotzdem diesen Weg gehen willst, es gibt einen Trick wie man 4 Vertices in den Geometryshader bekommt obwohl Quads dort natürlich auch nicht mehr unterstützt werden: Man verwendet einfach "LINES_ADJACENCY" als Eingabe in den Geometryshader, das besteht aus 4 Vertices pro Primitiv)

2) Das wäre theoretisch möglich, allerdings wahrscheinlich deutlich GPU rechenintensiver. Zum einen könntest du im Fragment Shader alle Pixel die nicht am Rand liegen transparent machen oder discarden, oder zum anderen wäre es möglich im Geometry Shader die Linie aus Dreiecken außenrum zu bilden.

Noch ein paar Tipps:
Den Index Buffer zum Rendern kannst du wiederverwenden.
Die Indices im Index Buffer können für alle Dreiecke gleich sein, du kannst also am Anfang einen allgemein geteilten Index Buffer anlegen. Du könntest auch versuche ein Triangle Strip zu verwenden und einen Primitive Restart Indexeinzusetzen... 5 Indices statt 6 pro Vertex - ob das positiv für die Performance ist, weiß ich aber nicht.

Funktionen mit "ARB" solltest du übrigens vermeiden. ;-)
So Dinge wie Buffer sind seit Ewigkeiten im Core(ohne ARB) und da Extensions einzusetzen,
kann zu Inkompatiblitäten führen. Auch mit neueren Features.


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Do Jan 22, 2015 15:48 
Offline
DGL Member

Registriert: Di Aug 23, 2005 09:15
Beiträge: 31
Programmiersprache: FPC/Delphi XE3
Danke, ich werde mich damit in die kommende Tagen beschäftigen.

Heute ist alles durch das Hochladen beschränkt (also die Daten nach der GPU kriegen, speziell auf Intel Hardware), nicht das Rendern. Darum denke ich das mehr Daten (Vertices oder Indizien) verzögern werden.

Danke für "Discard" Link, das ist etwas nachdem ich schon gesucht habe.

Ich muss auch mit Benchmarking usw von nichts neu anfangen, also es wird eine Weile brauchen.

(
Ziel Hardware: medium getakteten Ivy Bridge oder Haswell i5 CPU's, in mehr anstrengende Applikationen ein Radeon 5450 dazu.

Typische Opengl zeit (Hochladen+Rendern 4-6MB Bild mit etwas overlay) fuer Radeon fall: 5ms, Intel: 20ms. Wovon heutiges Rendern 500us oder so ist. Das ist nicht der Bottleneck. Intel (eben neuen 4600's) sind sehr langsam mit Textureupload. Merkwürdig ist das mein Radeon 7850(GCN) auch langsamer ist als der 5450(VLIW5?)

Framerates variieren bis sehr hoch (denke 80x 2048x2200x8bpp jede Sekunde), aber wir lassen nie mehr als 10-20 pro Sekunde zu OpenGL, weniger für Intel)
)


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Fr Jan 23, 2015 09:35 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Es ist extrem abhängig, was du genau erreichen willst.
Sind die Rechtecke statisch oder dynamisch und wieviele sind gleichzeitig sichtbar.
Ausgeschlossen werden kann schon mal ein IBO, denn IBO erzeugen bei einzelnen Quads mehrlast(mehr cache misses).
In der Praxis sogar schlimmer mit hardware instancing/geometry shader,denn bei 60-100 Triangle und mehreren hundert/tausend Instanzen kann die mehrlast von IBO nicht die kompaktere Datenhaltung von Triangle pro Byte ausgleichen.

Was gibt es für statische Lösungen ?
-vbo -> statisch, sehr schnell, sehr effizient wenn alle rechtecke sichtbar sind
-geometry shader + vbo(enthält GL_POINT's) -> statisch, sehr effizient wenn nur wenige rechtecke sichtbar sind
-hardware instancing + vbo(GL_TRIANGLE) -> gleich der vorigen Variante aber einfacher zu unterstützen

Dynamisch ?
-subdata update(extrem langsam, vorallem auf mobile, ineffizienter mit jeder dazu kommenden gpu generation)
-transform feedback(extrem schnell, skalierbar in die zukunft)
-compute shader(keine praktische Erfahrung, sollte aber um transform feedback herrum einordnen lassen und sonnst gleiche eigenschaften)
-shader uniforms(langsam) / UBO(schneller) / bindless UBO(nochmal schneller, wenn noch nach dem rechtecken was auf der GPU gerendert wird, OpenGL4.4)

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

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Fr Jan 23, 2015 15:09 
Offline
DGL Member

Registriert: Di Aug 23, 2005 09:15
Beiträge: 31
Programmiersprache: FPC/Delphi XE3
TAK2004 hat geschrieben:
Es ist extrem abhängig, was du genau erreichen willst.


Es ist, wie gesagt ein Overlay über ein laufendes Kamera Bild. Jeder Rechteck hat seine eigene 4 2D Koordinaten. (Jetzt noch glfloat). Die Rechtecke Bilden Pixelwerte über eine gewisse 8bit Intensität aus. Alle anschließende Pixel auf einen Horizontaler Linie bilden 1 Rechteck (also sind (fast) immer 1px hoch).

Im schlechtesten Fall gibst etwa 100000 Rechtecke. Wir versuchen das zu vermeiden weil das System einwandfrei weiter arbeiten muss, aber es kann ab und zu schon passieren.

Aufarbeiten bis weniger Rechtecke oder andere Vielecke ist nicht sehr Praktisch. Wurde sehr viel mehr Seit nutzen weil die Rechtecke dafür nicht geschickt vor sortiert sein.

Alle Rechtecken haben die Ecken in einen fester Ordnung. Koordinaten im Vertex Buffer werden nie mehrfach benutzt

Zitat:
Sind die Rechtecke statisch oder dynamisch und wieviele sind gleichzeitig sichtbar.


Jedes Bild eine neue Array, in Prinzip sind alle sichtbar.

Typisch wird eine "Szene" nur einmal gerendert, nur wenn ein Operator Pan und Zoom nutzt wird nochmal erneut gerendert. Renderzeiten (typisch 800us) sind heute viel weniger als upload Zeiten.

Es fällt auf das Intel IGPs Textures langsamer uploaden, aber VBO's schneller. (auf Sandy/Ivy Bridge hw)

Zitat:
Ausgeschlossen werden kann schon mal ein IBO, denn IBO erzeugen bei einzelnen Quads mehrlast(mehr cache misses).
In der Praxis sogar schlimmer mit hardware instancing/geometry shader,denn bei 60-100 Triangle und mehreren hundert/tausend Instanzen kann die mehrlast von IBO nicht die kompaktere Datenhaltung von Triangle pro Byte ausgleichen.


Ich habe keine Instanzen, kein hernutzbare Vertices. Ich habe in solchen Fall 1000000 einzigartige Rechtecke.

Zitat:
Was gibt es für statische Lösungen ?
-vbo -> statisch, sehr schnell, sehr effizient wenn alle rechtecke sichtbar sind


Nutze ich jetzt mit GL_QUAD, aber GL_QUAD ist deprecated in 3.1+? (Werde es immerhin benutzen bis nicht mehr geht weil IBO etwa 10% langsamer ist)

Ich arbeite heute daran die heutigen Implementation etwas zu modernisieren und speziell wolle ich eine andere Lösung für Fonts. (anders als wglusebitmap*), ist aber etwas
für ein andere Thread.


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Fr Jan 23, 2015 15:31 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Wenn ich das richtig verstehe, dann wäre das doch eher ein Fall für ein Screen Space Fragment Shader.
Also in ein Textur Target rendern, Shader binden und dann ein Fullscreen quad mit dem Rendertarget rendern.

Der Fragment Shader kann dann die Magic extrem effizient lösen.

Wegen Fonts kannst du distant field fonts mal anschauen.

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

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Fr Jan 23, 2015 16:57 
Offline
DGL Member

Registriert: Di Aug 23, 2005 09:15
Beiträge: 31
Programmiersprache: FPC/Delphi XE3
TAK2004 hat geschrieben:
distant field fonts mal anschauen.


Das war das Plan ja. Habe die mapbox-fontnik Demo schon Lokal ans laufen bekommen (noch immer Javascript) Hat jemand da für Pascal Kode? Oder eben C/C++ ?


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Fr Jan 23, 2015 18:08 
Offline
DGL Member

Registriert: Do Dez 29, 2011 19:40
Beiträge: 421
Wohnort: Deutschland, Bayern
Programmiersprache: C++, C, D, C# VB.Net
Ich arbeite momentan zufällig gerade an einem Rewritte meines Font Renderers. Diesmal mit besseren Caching und Distance Fields. Zum Generieren der Distance Fields verwende ich den "Dead Reckoning" Algorithmus(Pseudocode).
Die einzelnen Buchstaben rendere ich mit Freetype im voraus oder zur Laufzeit und packe sie einen Texturatlas. Diesen generiere ich nach dem Sortieren der Buchstabenmit dem Algorithmus von hier(C# Code).

Meine Umsetzung ist in C++.


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Fr Jan 23, 2015 19:27 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
http://www.angelcode.com/products/bmfont/ unterstützt das generieren mit vielen weiteren features wie Atlas generieren für bestimmte Sprachen oder gar Texte.
C++ code

Die Technik hat noch den Vorteil, dass man bis zu einem gewissen Grad noch Dropshadow, Outline oder Glow einfach mit nutzen kann.

Eine Alternative gibt es über VBO + Shader und ab OpenGL 4 dann einfach VBO(enthält die quadric bezier curve einer font(ttf nutzt solche um ein glyph zu beschreiben)) mit Tesselation Unit.
Beide varianten skalieren besser, weil sie nicht texel basiert sind, sondern die normale vertex/fragment pipeline benutzen.
Bei beiden Varianten sollte man überlegen noch ein eigenes AA im Fragment shader zu machen.
Weil wenn man AA für die App deaktiviert, dann wird das UI/Text wenigstens noch Treppenfrei gerendert :)

Ich hatte vor mitlerweile 5 Jahren O_o mit der VBO+Shader-Tesselation Variante rumgespielt.
Bild

Für mein Zero-Prime Projekt hatte ich Tesselation und VBO eingeplant aber noch nicht angefangen.

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

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Di Feb 03, 2015 12:43 
Offline
DGL Member

Registriert: Di Aug 23, 2005 09:15
Beiträge: 31
Programmiersprache: FPC/Delphi XE3
Ich habe jetzt eine Woche an diesem Projekt gearbeitet, aber bin noch nicht wirklich am Fonts daran gekommen, nur die heutige Code modernisieren.

Dabei habe ich einige Dingen herausgefunden:

- wenn man Textures mit dieselbe Parameter (Dimension, Pixeltyp) wiederholt hoch laden muss, (zb für Webcam/Film), dann kann man bestens den Texture hoch laden mit glmapbuffer move/unmapbuffer und das erste Mal Teximage2d, und danach texSUBimage2d nutzen. Intel ist Kritisch darauf(halbiert die Zeit) , AMD und Nvidia ist immer Teximage2d nutzen auch gut.

- Für Intel Haswell, unbedingt die neusten (Januar) Treiber Installieren. Die habe offenbar eine Zero-copy Optimierung. Ich hoffe das neue Treiber für Ivy Bridge dies auch Optimieren, aber die gibt es noch nicht.

- Intel Karten (Sandy/ivy Bridge und Haswell) sind sehr, sehr schnell mit das Hochladen von ARRAY_BUFFERS, und Haswell (sie oben) auch mit Textures. Scheller als zb mein HD7850

- Die GL_RECTS alternativ mit indexed Triangles funktioniert und ist nur marginal langsamer. Versuche Heute das zu machen mit Geometry Shader.

- Texture zeichnen über Shader ist kaum langsamer.


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Di Feb 03, 2015 14:00 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Ich tippe mal, dass deine HD7850 auf einem PCI-E Slots steckt.
Dann würde es die Kopiergeschwindigkeit erklären.
Die On-Chip Grakas haben einige Vorteile, z.B. in Stromverbrauch und Memory Bus Geschwindigkeit.

Wie ich vorher erwähnt habe, solltest du auf den index buffer verzichten und einfach 6 vertices in ein vbo packen und mit GL_TRIANGLES zeichnen.

Da du im Screenspace unterwegs bist würde ich das auch vollständig ausnutzen, indem du die vertices im -1 bis 1 bereich belässt und auf matrizen verzichtest.

Folgendes ist ein fullscreen squad
x,y,z
-1,-1,0
1,-1,0
1,1,0
-1,1,0

Im vertex Shader braucht man keine matrizen und übergibt die vertices einfach 1zu1 und spart ne menge unnötiger Berechnung. Ledeglich das Bildschirmformat ist interessant, wenn du richtig skalieren willst.

Du solltest eine Shader variable übergebe, welche die aspect ratio enthält.
vec2 reciprocal_aspect = vec2(screen.height/screen.width, 1.0f);

Dann kannst du im Shader folgendes machen.
vec3 position_in;
position_in *= reciprocal_aspect;

Das ist nur ein Beispiel, in reeller Umgebung muss man nach der Kantenlänge gucken und entsprechend die aspect ratio auf die jeweiligen Werte einstellen.
Ich hab den Kehrwert gebildet, weil ich dann multiplizieren kann, statt division.
Die Division passiert auf der CPU, die kann das ab aber auf der GPU passiert das ja viele mal mehr und da ist dann die Multiplikation schneller.

Das ganze ist Prozentual nicht Pixelgenau und skaliert damit problemlos auf jeder Auflösung und aspect Ratio mit wesentlich weniger Coding Aufwand.

Für pixelgenauigkeit müsste man ein layouting auf der CPU seite machen.

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

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Di Feb 03, 2015 14:23 
Offline
DGL Member

Registriert: Do Dez 29, 2011 19:40
Beiträge: 421
Wohnort: Deutschland, Bayern
Programmiersprache: C++, C, D, C# VB.Net
Zitat:
Wie ich vorher erwähnt habe, solltest du auf den index buffer verzichten und einfach 6 vertices in ein vbo packen und mit GL_TRIANGLES zeichnen.

Warum das?

Es spart Speicherbandbreite und nutzt dem Post Transform Cache aus. Es könnte also besser sein.


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Di Feb 03, 2015 14:53 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Wie ich bereits erwähnt hab, sind index erst ab bestimmten Mengen schneller.
In meinem Fall ~70 Triangle auf meiner R9 270, darunter ist die nutzung vom IBO langsamer als ohne.
Auf der GF760 gleiches Ergebnis aber ich weiß nicht wo da der Break-Even Point ist, da ich nur auf meiner den Profiler genutzt hab und auf der GF nur geprüft hab ob es nicht schlimmer geworden ist.

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

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: So Feb 08, 2015 18:19 
Offline
DGL Member

Registriert: Di Aug 23, 2005 09:15
Beiträge: 31
Programmiersprache: FPC/Delphi XE3
TAK2004 hat geschrieben:
Ich tippe mal, dass deine HD7850 auf einem PCI-E Slots steckt.
Dann würde es die Kopiergeschwindigkeit erklären.
Die On-Chip Grakas haben einige Vorteile, z.B. in Stromverbrauch und Memory Bus Geschwindigkeit.


In Theorie, Ja. Aber bis letzter Hasswell Treiber Update habe ich es nie gesehen (sehe eheren Posts). Sandy und Ivy Bridge sind noch immer ein Faktor zwei langsamer mit Texture upload.


Zitat:
Wie ich vorher erwähnt habe, solltest du auf den index buffer verzichten und einfach 6 vertices in ein vbo packen und mit GL_TRIANGLES zeichnen.


Ich habe es schließlich ganz anders getan, nämlich über Geometryshader mit zwei Punkte (Links Oben und Rechts Unter). Es war etwas schneller als alle andere Lösungen in Opengl mit der 7850. (gemessen als upload+zeichnen, 28MB Texture + 120000 Rechtecke, Texture ist etwa 4ms (3.2ms auf gleich getaktete Hasswell)), 841us for Upload rectecke, 200us vor rechtecke Zeichnen, 200us for texture zeichnen, 400 fuer HUD zeichnen (matrix Probleme die du erwähnst?) über alles etwa 7ms, aber das ist auch ein bisschen VCL refresh darin)

Ich muss noch mit Intel Hardware testen.

6 Vertices kommen überhaupt nicht in Frage. Denke daran das ich meistens Upload-, nicht Zeichnen limitiert bin. Daneben frisst das auch auf andere Stellen mehr CPU und Disk Bandbreite, und ich zeichne mehr nach Overlays (jedes Bild, bis 120/s) dann ich zeichne (max 10-20 /s)

Zitat:
Da du im Screenspace unterwegs bist würde ich das auch vollständig ausnutzen, indem du die vertices im -1 bis 1 bereich belässt und auf matrizen verzichtest.


Ich nutze Matrizen für Pan und Zoom. Man muss auf ein Defekt hineinzoomen können um es zich besser an zu sehen können. Ich habe mit der Texture Draw experimentiert mit Matrices oder direkt ausrechnen, aber es war egal. HUD funktionalitaet (push/popmatrix) ist aber etwas teurer (400 us nur fuer matrix operationen?!). Also ich werde das in gedanken halten.



Zitat:
Im vertex Shader braucht man keine matrizen und übergibt die vertices einfach 1zu1 und spart ne menge unnötiger Berechnung. Ledeglich das Bildschirmformat ist interessant, wenn du richtig skalieren willst.


(auch zoom und pan, X und Y unabhaengig. Und es gibt auch noch aspect ratio, eine Modus um Pixel viereckig zu halten, etwa min oder max ( viewport.height/texture.height, viewport.width,texture.width ) )

Zitat:
Das ganze ist Prozentual nicht Pixelgenau und skaliert damit problemlos auf jeder Auflösung und aspect Ratio mit wesentlich weniger Coding Aufwand.

Für pixelgenauigkeit müsste man ein layouting auf der CPU seite machen.


Pixelgenauigkeit ist wichtig, aber nur mit höher Zoom.

etwas code von meine experimenten:

Code:
  1.  
  2.     TGLRect = packed record
  3.               x1y1: TGLVertex;   // top left
  4.               x2y2: TGLVertex;   // bottom right
  5.               col:  TGLColor;      //  color
  6.               detail:integer;       // layer
  7.               end;
  8.  
  9. vertex:
  10. *#version 150 compatibility
  11. in vec2 pos1;
  12. in vec2 pos2;
  13. in vec4 color;
  14. in float rectdetail;
  15. out vec4 vColor;
  16. out vec2 x1y1;
  17. out vec2 x2y2;
  18. out float vdetail;
  19. void main() {
  20. vdetail=rectdetail;
  21. x1y1=pos1;
  22. x2y2=pos2;
  23. gl_Position = gl_ModelViewProjectionMatrix * vec4(pos1.xy,0,1.0);
  24. vColor = color;
  25. }
  26.  
  27. geo:
  28. *#version 150 compatibility
  29. layout(points) in;
  30. layout(triangle_strip, max_vertices = 6) out;
  31. in vec4 vColor[];
  32. in vec2 x1y1[];
  33. in vec2 x2y2[];
  34. in float vdetail[];
  35. out vec3 fColor;
  36. uniform float curdetaillevel;
  37. void main() {
  38. fColor = vec3(vColor[0].rgb);
  39.  if (vdetail[0]>curdetaillevel) {
  40.     gl_Position = gl_ModelViewProjectionMatrix * vec4(x1y1[0].xy,0,1.0);
  41.     EmitVertex();
  42.     gl_Position = gl_ModelViewProjectionMatrix * vec4(x2y2[0].x,x1y1[0].y,0,1.0);
  43.     EmitVertex();
  44.     gl_Position = gl_ModelViewProjectionMatrix * vec4(x1y1[0].x,x2y2[0].y,0,1.0);
  45.     EmitVertex();
  46. EndPrimitive();
  47.     gl_Position = gl_ModelViewProjectionMatrix * vec4(x2y2[0].x,x1y1[0].y,0,1.0);
  48.     EmitVertex();
  49.     gl_Position = gl_ModelViewProjectionMatrix * vec4(x2y2[0].xy,0,1.0);
  50.     EmitVertex();
  51.     gl_Position = gl_ModelViewProjectionMatrix * vec4(x1y1[0].x,x2y2[0].y,0,1.0);
  52.     EmitVertex();
  53. EndPrimitive();
  54. }
  55. }
  56.  
  57. frag:
  58. *#version 150 compatibility
  59. in vec3 fColor;
  60. out vec4 outColor;
  61. void main() {
  62.     outColor = vec4(fColor, 1.0);
  63. }
  64.  


ich habe noch versucht Detaillevel in alpha von Farbe zu packen, aber das funktioniert noch nicht. (Später hinzugefügt: Duh, logisch, Integer Farbe Werte werden normiert)


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Do Feb 02, 2017 21:42 
Offline
DGL Member

Registriert: Di Aug 23, 2005 09:15
Beiträge: 31
Programmiersprache: FPC/Delphi XE3
marcov hat geschrieben:
TAK2004 hat geschrieben:
Ich tippe mal, dass deine HD7850 auf einem PCI-E Slots steckt.
Dann würde es die Kopiergeschwindigkeit erklären.
Die On-Chip Grakas haben einige Vorteile, z.B. in Stromverbrauch und Memory Bus Geschwindigkeit.


In Theorie, Ja. Aber bis letzter Hasswell Treiber Update habe ich es nie gesehen (sehe eheren Posts). Sandy und Ivy Bridge sind noch immer ein Faktor zwei langsamer mit Texture upload.


Kleiner update:

Ich habe mittlerweile herausgefunden was der Problem war. Sandy und Ivy unterstutzen 8bit monochrome Textures nicht native, weil Haswell+ tuts :-)

Und ich nutze meistens mono Textures bis vor ein paar Monate.

P.s. ein Kaby Lake tut jetzt etwa 2.3ms (28MB texture+130000 rectecke, eine paar tausend Zirkel und linie und 15000 Karakter Text), als 33% schneller als Skylake, und fast zwei mal so schnell wie Haswell.


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 18 Beiträge ]  Gehe zu Seite 1, 2  Nächste
Foren-Übersicht » Programmierung » OpenGL


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 22 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.102s | 20 Queries | GZIP : On ]