Welchen Performancevorteil erwartest du bei Dxt5? Das braucht genausoviel Speicher wie R8, hat aber keine Artefakte, die man bei Distance Fields schnell merken würde. Ich habe bei mir festgestellt, dass R8 für Distance Fields schon äußerst knapp ist. Wenn ich den Bereich nicht für die Buchstabengröße optimal skaliere, kommt es schon zu sichtbaren Darstellungsfehlern bei der Vergrößerung. Die Kanten der Buchstaben fransen dann aus. Bei wirklich großen Buchstaben sind R16 notwendig. Für Halffloat sehe ich wenig Gründe: Das hat weniger Präzision als R16 und der höhere Dynamikumfang nützt bei Distance Fields auch wenig. (Distanzen sind schließlich linear über einen vorher absehbaren Bereich)

Bei "Lookuptables über Quadtree" sehe ich nicht den Vorteil gegenüber einer einzelnen normalen Texturen bzw. wäre es wahrscheinlich viel langsamer.

Ich erwarte kein Performancevorteil, die DXT Formate sind praktisch und Theoretisch die schnellsten Texturformate auf der GPU.
Es passiert ein Fetch, die gegossene Hardware kann daraus 16 Texel machen, bei gleicher Zeit wie ein Fetch auf ein R8 und zieht 1 Texel raus. Natürlich sind die nächsten fetches Cachehits und das bringt es wieder näher.
Auf den Desktop hab ich unter Last nur noch mit Profiler ein unterschied fest stellen können aber wenn man nicht viel rendert und noch ein paar hundert Frames hat, dann braucht man den Profiler nicht mehr um den Unterschied zu bemerken.
Bei iPad1 und nen älterem Android Smartphone HTC HD oder so ähnlich war der unterschied größer zu PVRTC und S3TC zu Luminance/R8/A8/... .

Man hackt sich sehr viel präzision weg, wenn man im Ganzahligen speichert, man bekommt ein color banding zu sehen.
Wenn man die Zahlen im float berechnet und dann als halffloat speichert ist der verlust extrem gering, da die Präzision um -1 bis 1 am höchsten ist und dann recht schnell ab nimmt. Das ist aber auch der Bereich der einen wirklich interessiert.
Halffloat ist auf dem Desktop nicht viel schneller als float aber auf Mobile schon. Das ist allerdings wie schon erwähnt nur sinnig, wenn man mehr Qualität braucht. Ich hatte Schriftzeichen aus dem Asiatischen raum gehabt, die sind teilweise extrem komplex und brauchen viel detail.

Letzlich haben wir dann DXT5 mit etwar größeren Glyphen genommen und die kleiner gerendert, dass versteckt die schlechte quali ziemlich gut xD Das ist vieleicht nicht die beste Lösung aber man muss halt mit Tradeoffs leben(ein Laster der Spieleindustrie, mit dem ich zu leben gelernt habe) :\

Lookuptables über Quadtree ist was recht neues, womit sich AMD, Nvidia, Microsoft, diverse Sony Studios und einige andere eine Paper Schlacht liefern. Das ist für Virtual Texture, Clipmapping und Voxel rendering mir diverse male unter die Augen gekommen. Dabei nutzt man Ganzzahlen, Bitsets oder auch mal Linked Lists verpackt über DX11-12 oder OpenGL4.

Bei DX12 kann man ja Virtual Texture direkt verwenden, das kümmert sich um das erfassen und nachladen von benötigten Texturbereichen aber bei OpenGL ist das noch ziemlich hackie. Im vergleich zu den bisherigen Lösungen läuft das komplett auf GPU Hardware und nicht mit CPU Analyse der gerenderten Szene.

Ich gehe davon aus, dass es langsamer ist, da man ja ein Indirekten Zugriff für die Lookuptable hinzu bekommt.
Die Frage ist, ist es so gering, dass der Vorteil von dynamisch Updatebaren Glyphen es rechtfertigt.
Praktisch konnte ich da noch nix testen aber mal abwarten, Doom4 wir dieses Jahr auf der QuakeCon vorgestellt und vieleicht bekommen wir ein paar Papers. Bevor Carmack ging hatte er in nem Interview gesagt, dass D4 auch Voxel verwendet(bestimmt Global Ilumination) und das Mega Texture stark verbessert wurde.

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

Projekte: https://github.com/tak2004

Ich mach noch ein Nachtrag, nachdem mir das heute in der Bahn noch durch den Kopf ging.
Meine Benchmarks und Profilings für die Pixelformate sind von vor fast 3Jahren also gf7xx, iPad2 Zeit rum.
Die gf8 und 9 haben im Befehlsduchsatz stark zugenommen, Speicherbandbreite ist aber kaum gestiegen und das könnte die Lücke zwischen S3TC und Luminance/R8/Alpha8 ausreichend verkleinert haben.

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

Projekte: https://github.com/tak2004

Meinst du, die Hardware macht das nicht auch mit anderen Formaten? Meines Wissens werden Texturdaten zur Optimierung generell speziell angeordnet. So ähnlich der Z-Kurve. Ich würde davon ausgehen, dass die Hardware immer ganze Blöcke in den Cache lädt, auch wenn keine Texturkompression verwendet wird? So ähnlich wie das auf der x86/x64 CPU immer eine ganze Cache Line(64 Byte) vom RAM angefordert wird, auch wenn nur ein einzelnes Byte für einen R8-Texel angefordert wurde?
Vielleicht ist es nur auf Mobile-Hardware anders?


Selbst verständlich muss man die Zahlen noch richtig skalieren. Wenn man Texel-Distanzen speichert, sind Werte von 0 - 65535 natürlich schwachsinnig. Aber man kann die Werte richtig skalieren und erhält dann bessere Ergebnisse als mit Half Floats. Nimmt man zum Beispiel den Faktor 1/512 hat man den Bereicht 0 - 127 und kann auf einen 512stel Texel genau speichern. Die "Subtexel"-Präzision ist sehr wichtig wie ich festgestellt habe. Ansonsten kommt es schnell zu unregelmäßig gewellten Kanten bei Distance Fields. Halffloats(bzw. Fließkommazahlen generell) skalieren automatisch. Man erhöht den Dyamikumfang, verliert durch das Speichern des Wertebereiches aber Bits für die Präzision. Halffloats besitzen nur 11 Bits an Präzision. Die restlichen 6 bzw. 7 Bits gehen für das Speichern des Wertebereich drauf("Exponent"). In dem gleichen Szenario mit Buchstaben in der Größe von 0 bis 127, hätte man bei 127 damit nur noch eine Präzision auf 64/(2^11)=1/32 stel Texel(64 ist der Wert des Exponenten in dem Beispiel mit 127, die 11, sind die Bits in der Mantisse des Halffloats). Kleine Distanzen werden natürlich genauer gespeichert, aber größere sehr viel ungenauer. Ich sehe Distance Fields als typischen Anwendungsfall für Festkommazahlen, schließlich habe ich einen bekannten Wertebereich, über den ich Werte linear mit gleicher Präzision speichern möchte. Wenn ich einen Dickeeffekt auf die Schrift anwende, möchte ich keine unschärferen Buchstaben. Wenn man optimal skaliert, kommt ich ja gerade so auch mit 8 Bits (R8) aus. Das spart am meisten Bandbreite, wenn möglich.

An Sparse Texturen habe ich auch schon gedacht. Das könnte die Verwaltung des Texturatlasses vereinfachen und theoretisch Speicherplatz sparen. Ich habe bisher davon aber Abstand genommen, weil die einzelnen Texturen der Buchstaben vermutlich viel kleiner sind als eine Texture Page(das heißt, wenn man nicht ~90% des Platzes verschwenden möchte hat man enormen Verwaltungsaufwand mehrere Buchstaben in eine Texture Page zu bekommen) und die Erweiterung noch wenig unterstützt wird.

Ja die Formate Cachen alle, sogar recht viel aber S3TC ist cachefreundlicher.
Wer wie cached weiß ich nicht, schwer was zu finden.
Ich hab nur einmal Konkrete Zahlen zu den Rasterunits gelesen, in einem Simplygon Paper haben die geschrieben, dass 16x16-32x32 Blöcke pro Rasterunit zugewiesen sind und diese sich dann daraum kümmert diese Pixel zu rendern.
Dies passiert scanline aber texturen sind selten horizontal ausgerichtet und textur filtering macht lineares lesen auch unbrauchbar.
Blöcke sind dann effizienter.

Wenn man z.B. MipMaps abschaltet und seine Texturen ortho 1zu1 mit halftexel offset auf den Bildschirm rendert, hat man die optimale ausnutzung der Hardware. Da kein filtern zuschlägt und bilder pixelgenau abgebildet werden.

Ich hoffe doch, dass die rasterunit versucht ein boundingrect aus den uv koordinaten an den edges zu ermitteln und diese an zu fordern, damit texel fetches nicht auf den VRAM sondern auf ein L2-L3 Cache treffen aber schwer was zu zufinden.

Ich frag mich auch ob die Texeldaten im Cache liegen oder schon die swizzeld und entpackte 4x4 block Farben sind.

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

Projekte: https://github.com/tak2004

Ich hab mich gestern mal wieder ein bisschen mit dem Thema Textrendering beschäftigt und speziell mit den neuen Möglichkeiten.
Tesselation Unit ist leider ziemlich lahm und wird schnell ineffizient, wenn Schrift kleiner wird.

Ich hab ne Geometry Shader Variante gefunden, die Hoppe seine Arbeit auf greift und performanter macht aber solange man keine animierten Vektorgrafiken hat ist es nicht lohnenswert.

Also muss ich sagen, dass selbst mit GL4.5 Textur basierte Schriften das effizienteste sind.
OpenGL 4 bietet hardware Sparse Texture, dass will ich mal austesten, ob es Performanceeinbußen hat und wenn ja wie hoch.
Theoretisch nicht, weil es Hardware gestützt passiert und ASync. Man hinterlegt einfach die Speicheradresse im Arbeitsspeicher und beschreibt dann in der Texture die Datenstruktur.
Jedes mal, wenn Daten nicht im VRAM liegen, tut die Graka das benötigte Tile nachladen.
Sparse Texture
Sparse Texture wurde von AMD Entwickelt und ist ARB in 4.3 und auch von NV unterstützt.
Das ganze kann aber maximal 16kx16kx2k groß sein und in der Präsi ist auch ein vergleich zur Shader Lösung(die geht auch mit OpenGL 1.5(hatte ich für meine Bachelor Arbeit gemacht),2,3).

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

Projekte: https://github.com/tak2004