SSL-Beschleunigung mit modernen 3D-Grafikkarten

Kirbach, Christian

SSL-Beschleunigung mit modernen 3D-Grafikkarten

Zusammenfassung

Inhaltsangabe:Einleitung:
Die sichere Übertragung von Informationen in Computernetzen und speziell die Sicherheit im Internet sind von wachsender Bedeutung. Insbesondere konsumentenorientierte Dienste wie z.B. Online-Shopping, Online-Banking und Online-Auktionen stellen eine steigende Herausforderung dar. Sie müssen eine wachsende Kundenzahl mit einer dementsprechend zunehmenden Menge an Daten beliefern.
Zum Schutz der Privatsphäre und sensibler Daten müssen diese verschlüsselt übertragen werden. Nur so kann der Sicherheitsdienst Vertraulichkeit gewährleistet werden. Neben der Verschlüsselung der Kommunikation stehen weitere Sicherheitsmechanismen in Form kryptographischer Verfahren zur Verfügung, mit denen weitere Sicherheitsdienste wie die Datenunversehrtheit oder auch Datenintegrität und die Authentikation der Kommunikationspartner erbracht werden können. Zahlreiche Sicherheitsprotokolle für das Internet und auf IP basierende Protokolle und Anwendungen liegen als Standards vor und adressieren die Authentikations-, Integritäts- und Vertraulichkeitsanforderungen des jeweiligen Einsatzgebietes.
Zur verschlüsselten Übertragung des HTTP-Protokolls wird überwiegend der Secure Socket Layer (SSL) verwendet. Ursprünglich von Netscape entwickelt, wird SSL mittlerweile von der IETF unter dem Namen Transport Layer Security (TLS) standardisiert. SSL/TLS sichert TCP-Verbindungen, die auch vom HTTP-Protokoll verwendet werden. Während des Verbindungsaufbaus werden asymmetrische kryptographische Verfahren zur Authentikation der Kommunikationspartner und zur Einigung auf einen gemeinsamen geheimen, d.h. symmetrischen Schlüssel verwendet. Der mit asymmetrischen Verfahren ausgehandelte symmetrische Schlüssel wird im Anschluss zur Verschlüsselung der Sitzung verwendet.
Ein großer Nachteil des SSL/TLS-Protokolls ist der hohe Rechenaufwand während des Verbindungsaufbaus mit asymmetrischer Kryptographie. Es sind spezielle Beschleunigerkarten auf dem Markt erhältlich, die für asymmetrische kryptographische Berechnungen ausgelegt sind. Die Karten können die anfallende Rechenlast übernehmen und entlasten auf diese Weise den Hauptprozessor von z.B. SSL-Servern. Aufgrund der deutlichen Leistungssteigerung durch den Einsatz von SSL-Beschleunigerkarten werden diese häufig von den Betreibern vieler SSL-Server eingesetzt. Abbildung 1.1 zeigt beispielhaft eine solche Karte. Es ist das Modell AXL600L der Firma HP und wird in einer Version als PCI-Karte vertrieben. Hohe […]

Leseprobe

Inhaltsverzeichnis

Christian Kirbach

SSL-Beschleunigung mit modernen 3D-Grafikkarten

ISBN: 978-3-8366-1310-1

Druck Diplomica® Verlag GmbH, Hamburg, 2008

Zugl. Universität Siegen, Siegen, Deutschland, Diplomarbeit, 2005

Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,

insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von

Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der

Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,

bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung

dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen

der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik

Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich

vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des

Urheberrechtes.

Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in

diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,

dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei

zu betrachten wären und daher von jedermann benutzt werden dürften.

Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können

Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die

Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine

Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.

http://www.diplom.de, Hamburg 2008

Printed in Germany

Danksagung

Ich widme diese Seite allen Personen, die zur Entstehung dieser Diplomarbeit in

unersetzbarer Weise beigetragen haben.

An erster Stelle richtet sich mein Dank an meine Eltern für ihre durchgehende Unterstützung

und Befürwortung meines Studiums. Ich danke für die wissenschaftliche Betreuung

Univ.-Prof. Dr. Christoph Ruland und Dipl.-Ing. Luigi Lo Iacono vom Lehrstuhl für digitale

Kommunikationssysteme der Universität Siegen. Ebenso bedanke ich mich für die

freundliche Zusammenarbeit und Unterstützung bei Dipl.-Inf. Nicolas Cuntz vom Lehrstuhl

für Computergrafik für die ständige Hilfestellung bei Fragen zur Implementierung und seinen

Anregungen zu neuen Lösungsansätzen.

Mein besonderer Dank gilt auch Dipl.-Inf. Dominik Göddeke vom Institut für Angewandte

Mathematik und Numerik der Universität Dortmund. Er hat mir freundlicherweise Zugang zu

seinem noch unveröffentlichten Tutorial gegeben.

Mein Dank gilt allen Korrekturlesern und -leserinnen: Dipl.-Ing. Andre Schäfer, Katharina

Kirbach, Gunnar Spickermann, Hendrik Payer, Stefan Siebel und Dirk Sommer.

Zusammenfassung

Datenaustausch über das Internet gewinnt zunehmend an Bedeutung. Viele Geschäftsberei-

che verlassen sich schon heute auf verschlüsselte Kommunikation, wie z.B. Online Banking

und Online Shopping. Dabei erfordert insbesondere die Verwendung asymmetrischer krypto-

graphischer Verfahren zur Absicherung der Kommunikation viel Rechenleistung. Aus diesem

Grund setzen die Betreiber von Internet-Servern spezielle Hardware-Beschleunigerkarten ein.

Sie übernehmen die aufwendigen Berechnungen und entlasten so die CPU der Server. Ein

Nachteil dieser Krypto-Hardware sind hohe Anschaffungskosten. Der wachsende Bedarf nach

Sicherheit in Informations- und Kommunikationssystemen beflügelt die Suche nach Alterna-

tiven, um die enorme Rechenlast zu bewältigen.

Moderne 3D-Grafikkarten sind in den letzten Jahren besonders leistungsstark geworden. Ihr

jährliches Leistungswachstum übertrifft sogar das der verbreiteten Mikroprozessoren. Ein

großer Verkaufsumsatz hat sie zu günstiger Massenware werden lassen. Zusätzlich macht sie

eine steigende Programmierbarkeit sehr flexibel. Die moderne Wissenschaft nutzt Grafikpro-

zessoren schon heute zur Berechnung von Finite Elemente Simulationen und hochauflösenden

Computertomographien in Echtzeit. Neue Anwendungsbereiche werden ständig erschlossen.

Im Rahmen dieser Diplomarbeit wird die Möglichkeit analysiert und bewertet, moderne 3D-

Grafikkarten für die Berechnungen asymmetrischer kryptographischer Operationen einzuset-

zen. Insbesondere wird der weit verbreitete RSA-Algorithmus untersucht, welcher auf Expo-

nentiationen von sehr großen Ganzzahlen und Modulo-Operationen basiert. Eine geeignete

Grafikbibliothek wie das Plattform übergreifende OpenGL ist erforderlich, um alle Opera-

tionen zu steuern. Sie wird eingesetzt, um Daten von und zur Grafikkarte zu transferieren

und die erforderlichen Rechenvorgänge des Grafikprozessors anzustoßen. Die programmier-

baren Einheiten des Prozessors werden mit Hilfe der Programmiersprache Cg programmiert,

ein Derivat der Hochsprache C, das speziell auf die Programmierung von Grafikprozessoren

angepasst wurde. Hardware übergreifende Cg-Profile stellen sicher, dass die Programme auf

einer Vielzahl von Grafikkarten eingesetzt werden können.

Zum Schluss wird die Geschwindigkeit dieser Implementierung mit der von gängigen RSA-

Implementierungen verglichen, die ausschließlich Berechnungen auf der CPU durchführen.

III

Abstract

Secure internet communications are constantly becoming more important. Lots of businesses

rely on encrypted transactions, e.g. online banking and online shopping. In particular asym-

metric SSL encryption requires lots of computational power. Dedicated hardware accelerator

cards are usually deployed at large server sites. They perform expensive calculations efficient-

ly in favour of the server's CPU. One major drawback of cryptographic hardware is their

high price tag. As demand for security increases new possibilities are embraced to handle the

workload.

3D graphics cards have become increasingly powerful mainstream products in recent years.

Their power growth rate even exceeds general purpose microprocessors. They are in mass pro-

duction and cheap. Additionally improving programming capabilities have turned them into

flexible and versatile devices. Modern science already computes finite element simulations

and high-resolution real-time computer tomography on graphics processors. New applications

continue to emerge.

This thesis analyses and evaluates the possibility of harnessing the power of modern 3D gra-

phics cards for asymmetric cryptography. In particular the popular RSA algorithm is exami-

ned. It involves computing the power of large integer numbers and modulus operations. A

suitable graphics library like the cross-platform OpenGL is required for controlling all nec-

cessary operations. It is used to perform data transfers to and from the graphics card and

initiate calculations done by GPU programs. These shader programs will be written in the Cg

programming language, a derivative of C adjusted for GPU programming. Vendor independent

Cg profiles ensure that programs can be compiled for a variety of cross-vendor GPUs.

Finally the performance will be evaluated and compared to state-of-the-art RSA implementa-

tions that run on CPUs.

Inhaltsverzeichnis

1 Einleitung

2 Moderne 3D-Grafikkarten

2.1 Einbindung in die Computerarchitektur . . . . . . . . . . . . . . . . . . . .

2.2 Die Render-Pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.3 Der Vertex-Shader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.4 Der Fragment-Shader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 Programmierung von 3D-Grafikkarten

3.1 Zusammenspiel beteiligter Komponenten . . . . . . . . . . . . . . . . . . .

3.2 OpenGL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.3 Direct3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.4 Cg - C for Graphics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.5 Fragment-Programme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4 Modulare Langzahl-Arithmetik

4.1 Integer-Multiplikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2 Parallelisierung der Integer-Multiplikation . . . . . . . . . . . . . . . . . . .

4.2.1

Parallelisierung mit eindimensionalen Gittern . . . . . . . . . . . . .

4.2.2

Parallelisierung mit zweidimensionalen Gittern . . . . . . . . . . . .

4.3 Modulo-Berechnung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.4 Modulare Exponentiation . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.4.1

Square-and-Multiply Algorithmus . . . . . . . . . . . . . . . . . . .

4.4.2

Links-nach-rechts Methode . . . . . . . . . . . . . . . . . . . . . .

4.4.3

Rechts-nach-links Methode . . . . . . . . . . . . . . . . . . . . . .

4.4.4

Sliding Window Exponentiation . . . . . . . . . . . . . . . . . . . .

5 Implementierung

5.1 Anforderungen und Rahmenbedingungen . . . . . . . . . . . . . . . . . . .

5.2 Systemarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.3 Realisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.3.1

Datenformate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.3.2

Frame Buffer Objects . . . . . . . . . . . . . . . . . . . . . . . . . .

5.3.3

Erzeugung von Texturen . . . . . . . . . . . . . . . . . . . . . . . .

5.3.4

Transfer von Texturdaten . . . . . . . . . . . . . . . . . . . . . . . .

5.3.5

Berechnung der Partialprodukte . . . . . . . . . . . . . . . . . . . .

Inhaltsverzeichnis

5.3.6

Bildung der Spaltensummen . . . . . . . . . . . . . . . . . . . . . .

5.3.7

Verarbeitung der Überträge . . . . . . . . . . . . . . . . . . . . . . .

5.4 Funktionsübersicht der Implementierung in C . . . . . . . . . . . . . . . . .

5.5 Tests und Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6 Integration in OpenSSL

6.1 API für OpenSSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.2 Änderungen an OpenSSL . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.2.1

Anpassungen am Quellcode . . . . . . . . . . . . . . . . . . . . . .

6.2.2

Änderungen an Makefiles . . . . . . . . . . . . . . . . . . . . . . .

7 Evaluierung

7.1 Vergleich mit CPU-Lösung . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.2 Zeitbedarf wichtiger Operationen . . . . . . . . . . . . . . . . . . . . . . . .

7.3 Ansatzpunkte für Verbesserungen . . . . . . . . . . . . . . . . . . . . . . .

8 Zusammenfassung und Ausblick

Literaturverzeichnis

A Installation der Software

A.1 Systemvoraussetzungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A.2 Installationsanweisungen . . . . . . . . . . . . . . . . . . . . . . . . . . . .

B Hilfs- und Testanwendungen

B.1 Java-Applikation zum Vortrag . . . . . . . . . . . . . . . . . . . . . . . . .

B.2 Messfunktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

B.3 Testfunktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

C Messergebnisse

C.1 Zeitnahme mit GPU-Implementierung . . . . . . . . . . . . . . . . . . . . .

C.2 Wichtige Teilberechnungen der GPU-Implementierung . . . . . . . . . . . .

C.3 Zeitmessungen von CPU-Lösungen . . . . . . . . . . . . . . . . . . . . . .

D Die Software zur Diplomarbeit

Abbildungsverzeichnis

1.1 Dedizierte PCI-Karte zur SSL-Beschleunigung (HP AXL600L) . . . . . . . .

1.2 Ein typischer Grafikprozessor (NVidia NV40) . . . . . . . . . . . . . . . . .

2.1 Einbindung der GPU in moderne Rechnerarchitekturen [FHWZ04] . . . . . .

2.2 Schema der programmierbaren Render-Pipeline einer modernen GPU [RS05]

2.3 Translation und Rotation von Vertices (Raumpunkten) im Vertex-Shader [Bee02]

2.4 Reflexion eines Lichtstrahls an einer Oberfläche [RS05] . . . . . . . . . . . .

2.5 Von o. nach u. additiv: ambientes, diffuses und spiegelndes Shading einer Ku-

gel [RS05] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1 Anwendungsmöglichkeiten von Cg-Programmen . . . . . . . . . . . . . . .

3.2 Prinzipielle Arbeitsweise eines Fragment-Shaders mit »Multiple Render Tar-

gets« . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.1 Multiplikation nach dem »Schulalgorithmus« . . . . . . . . . . . . . . . . .

4.2 Matrix der Partialprodukte einer Multiplikation zweier N-Bit Zahlen . . . . .

4.3 Topologie eines eindimensionalen Gitters . . . . . . . . . . . . . . . . . . .

4.4 Parallele Multiplikation in einem eindimensionalen Gitter [Lei97] . . . . . .

4.5 Faltung zweier binärer Vektorkomponenten in eindimensionalem Gitter [Lei97] 24

4.6 Parallele Multiplikation in einem Mesh-of-Trees Netz [Lei97] . . . . . . . .

4.7 Carry-Save Addition mit einem Bitprozessor [Lei97] . . . . . . . . . . . . .

4.8 Skalierbares Netzwerk zur Reduktion der Addition von N auf N - 1 Zahlen

[Lei97] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.9 Binärer Baum aus 2-Bit-Addierern zur Summierung der Werte in den Blättern

[Lei97] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.1 Die Anjuta Entwicklungsumgebung (Version 1.2.2) . . . . . . . . . . . . . .

5.2 Compiler- und Linkereinstellungen des Projektes in Anjuta . . . . . . . . . .

5.3 Die Systemarchitektur im Überblick . . . . . . . . . . . . . . . . . . . . . .

5.4 Anordnung der Eingabefaktoren a und b in einer Textur . . . . . . . . . . . .

5.5 Anordnung der Ergebnisstellen in einer Textur . . . . . . . . . . . . . . . . .

5.6 Ausschnitt aus der Anordnung der Partialprodukte in einer Textur . . . . . .

5.7 Bildung der Spaltensummen in einer Textur . . . . . . . . . . . . . . . . . .

5.8 Verarbeitung der Überlaufe für ein Ergebnis aus sechs Blöcken . . . . . . . .

6.1 Die Systemarchitektur zur Einbindung in OpenSSL . . . . . . . . . . . . . .

7.1 Zeitmessung auf GeForce 6600 mit NVidia Treiber 1.0-7667 . . . . . . . . .

VII

Abbildungsverzeichnis

7.2 Zeitmessung auf GeForce 6600 mit NVidia Treiber 1.0-7676 . . . . . . . . .

7.3 Zeitdifferenz der Messwerte der beiden eingesetzten Treiberversionen . . . .

7.4 Zeitbedarf der drei Teilfunktionen bei steigenden Wiederholungen . . . . . .

B.1 Java-GUI der Demonstration unmittelbar nach Aufruf . . . . . . . . . . . . .

B.2 Java-Demonstration nach Ausführung einer Langzahl-Multiplikation . . . . .

VIII

1 Einleitung

Die sichere Übertragung von Informationen in Computernetzen und speziell die Sicherheit im

Internet sind von wachsender Bedeutung. Insbesondere konsumentenorientierte Dienste wie

z.B. Online-Shopping, Online-Banking und Online-Auktionen stellen eine steigende Heraus-

forderung dar. Sie müssen eine wachsende Kundenzahl mit einer dementsprechend zuneh-

menden Menge an Daten beliefern. Zum Schutz der Privatsphäre und sensibler Daten müs-

sen diese verschlüsselt übertragen werden. Nur so kann der Sicherheitsdienst Vertraulichkeit

gewährleistet werden. Neben der Verschlüsselung der Kommunikation stehen weitere Sicher-

heitsmechanismen in Form kryptographischer Verfahren zur Verfügung, mit denen weitere

Sicherheitsdienste wie die Datenunversehrtheit oder auch Datenintegrität und die Authenti-

kation der Kommunikationspartner erbracht werden können. Zahlreiche Sicherheitsprotokolle

für das Internet und auf IP basierende Protokolle und Anwendungen liegen als Standards vor

und adressieren die Authentikations-, Integritäts- und Vertraulichkeitsanforderungen des je-

weiligen Einsatzgebietes.

Zur verschlüsselten Übertragung des HTTP-Protokolls wird überwiegend der Secure Socket

Layer (SSL) verwendet. Ursprünglich von Netscape entwickelt, wird SSL mittlerweile von

der IETF unter dem Namen Transport Layer Security (TLS) standardisiert. SSL/TLS sichert

TCP-Verbindungen, die auch vom HTTP-Protokoll verwendet werden. Während des Ver-

bindungsaufbaus werden asymmetrische kryptographische Verfahren zur Authentikation der

Kommunikationspartner und zur Einigung auf einen gemeinsamen geheimen, d.h. symmetri-

schen Schlüssel verwendet. Der mit asymmetrischen Verfahren ausgehandelte symmetrische

Schlüssel wird im Anschluss zur Verschlüsselung der Sitzung verwendet.

Ein großer Nachteil des SSL/TLS-Protokolls ist der hohe Rechenaufwand während des

Verbindungsaufbaus mit asymmetrischer Kryptographie. Es sind spezielle Beschleunigerkar-

ten auf dem Markt erhältlich, die für asymmetrische kryptographische Berechnungen ausge-

legt sind. Die Karten können die anfallende Rechenlast übernehmen und entlasten auf diese

Weise den Hauptprozessor von z.B. SSL-Servern. Aufgrund der deutlichen Leistungssteige-

Abbildung 1.1: Dedizierte PCI-Karte zur SSL-Beschleunigung (HP AXL600L)

1 Einleitung

rung durch den Einsatz von SSL-Beschleunigerkarten werden diese häufig von den Betreibern

vieler SSL-Server eingesetzt. Abbildung 1.1 zeigt beispielhaft eine solche Karte. Es ist das

Modell AXL600L der Firma HP und wird in einer Version als PCI-Karte vertrieben. Hohe

Anschaffungskosten sind ein wesentlicher Nachteil von SSL-Beschleunigern. Das aufgeführ-

te Modell hat einen Neupreis von ca. US $2000. Diese dedizierte Krypto-Hardware ist keine

Massenware; ihr Preis begründet sich in einem geringen Produktionsvolumen. Mögliche güns-

tigere Alternativen sind bislang nicht ersichtlich.

Ein potentieller Ersatz für Krypto-Hardware sollte in vergleichbarer Zeit die selben Berech-

nungen ausführen können. Falls die Alternative nicht vergleichbar leistungsfähig ist, muss sie

zumindest deutlich kostengünstiger sein, damit sie attraktiv ist. SSL-Beschleuniger verfügen

über eine speziell entworfene Logik, die sehr schnell und effizient arbeitet. Eine vergleichbar

leistungsfähige Alternative zu kleinerem Preis ist daher unwahrscheinlich. Das letzte Argu-

ment führt zu dem Schluss, dass eine kostengünstigere, aber vermutlich leistungsschwächere

Ersatzlösung wahrscheinlich ist.

3D-Grafikkarten sind in den letzten Jahren durch starke Nachfrage und hohem Konkurrenz-

druck im Markt zu sehr leistungsfähigen und preiswerten Produkten geworden. Gleichzei-

tig ist die Programmierbarkeit des Grafikprozessors deutlich gesteigert worden. Durch die

neu gewonnene Flexibilität eröffnen sich ständig neue Anwendungsbereiche [XM05, WW04,

Goe05, MA03, Kla03, ThO02]. Abbildung 1.2 zeigt beispielhaft die Ober- und Unterseite

eines typischen Grafikprozessors. Moderne Grafikprozessoren arbeiten intern mit starker Par-

allelverarbeitung; sie können als Parallelprozessoren angesehen werden.

Abbildung 1.2: Ein typischer Grafikprozessor (NVidia NV40)

Für die asymmetrische oder auch Public-Key Kryptographie ist der RSA-Algorithmus weit

verbreitet. Der Algorithmus erfordert die Exponentiation und die Modulo-Berechnung von

sehr großen ganzzahligen Operanden. Für diese mathematischen Operationen existieren zahl-

reiche Algorithmen für Parallelprozessoren [BS03b, Lei97]. Es sind aber auch Algorithmen

für Allzweck-Mikroprozessoren [Knu97, BR89, Möl03] und abgestimmte Entwürfe für eine

Implementierung in Hardware [Lee76, BS03a] entwickelt worden.

Gegenstand dieser Diplomarbeit ist die Untersuchung, ob und in welchem Maße sich mo-

derne 3D-Grafikkarten für mathematische Berechnungen der Kryptographie nutzen lassen.

Im Speziellen wird eine Umsetzung der rechenintensiven asymmetrischen Verschlüsselung

1 Einleitung

des weit verbreiteten RSA-Algorithmus analysiert. Es wurde bereits gezeigt, dass mit Hilfe

von 3D-Grafikkarten symmetrische Verschlüsselung möglich ist [CIK04]. Die Untersuchung

kam zu dem Ergebnis, dass sich der Einsatz von Grafikkarten lohnen kann. Die verbreiteten

Mikroprozessoren in Computersystemen können symmetrische Verschlüsselung sehr effizient

durchführen. Grafikkarten sind nicht in der Lage die Berechnungen genauso schnell durchzu-

führen, ihr zusätzlicher, unterstützender Einsatz ist aber laut der Studie lohnenswert.

In den Kapiteln 2 und 3 werden die Arbeitsweise von modernen 3D-Grafikkarten und

die Möglichkeiten ihrer Programmierung näher beschrieben. Kapitel 4 erörtert die modulare

Langzahl-Arithmetik. Sie ist Grundlage für eine Umsetzung des RSA-Algorithmus. Kapitel 5

und 6 beschreiben die in den Programmiersprachen C und Cg neu entwickelte Implementie-

rung einer Multiplikation zweier langer Ganzzahlen und gehen auf die Integration der Lösung

in die freie SSL-Bibliothek OpenSSL ein. Die Arbeit schließt mit der Evaluierung der Ge-

schwindigkeit des Algorithmus und zeigt in einem Ausblick weiterführende Entwicklungen

und potentiellen Optimierungen auf.

2 Moderne 3D-Grafikkarten

Grafikkarten sind für die Ausgabe von Text und Grafiken auf Bildschirmanzeigen verant-

wortlich. Sie sind wichtiger Teil der Interaktion eines Computers mit dem Benutzer. Moder-

ne 3D-Grafikkarten bestehen im Wesentlichen aus einem Grafikprozessor (GPU - Graphics

Processing Unit) und schnellem, lokalem Arbeitsspeicher. Eine GPU ist ein auf Vektor- und

Matrixoperationen spezialisierter Mikroprozessor. Er übernimmt bestimmte rechenintensive

Aufgaben der 3D-Computergrafik und ist hierauf zugeschnitten. Moderne Grafikprozessoren

sind seit etwa 2001 durch zunehmende Programmierbarkeit sehr flexibel. Die GPU kann auf

den Videospeicher lesend und schreibend mit hoher Bandbreite und Geschwindigkeit zugrei-

fen [RS05]. Grafikprozessoren sind insbesondere in den letzten Jahren - angetrieben durch

den Massenmarkt der Computer- und Videospiele - zu sehr leistungsstarken Prozessoren wei-

terentwickelt worden. Zur Verdeutlichung dient ein Vergleich zwischen einem gängigen ak-

tuellen Mikroprozessor, dem Intel Pentium 4, und dem Grafikprozessor NV40 von nVidia.

Grafikkarten mit diesem Prozessor sind unter dem Namen »GeForce 6800« auf dem Markt

erhältlich.

Intel Pentium 4 (»Prescott«)

Erschienen am: 2. Februar 2004

3.000 MHz Taktrate

125 Millionen Transistoren

max. theoretische Leistung: 6 GFLOPS

nVidia NV40

Erschienen am: 1. Juni 2004

400 MHz Taktrate

225 Millionen Transistoren

max.

theoretische

Leistung:

GFLOPS

Gemessen an der Anzahl theoretisch möglicher Fließkommaoperationen pro Sekunde (FLOPS)

ist der Grafikprozessor um mehr als Faktor zehn schneller als die CPU. Für dieses mehr an

Leistung genügt weniger als die doppelte Anzahl an Transistoren. Zusätzlich ist beachtens-

wert, dass die GPU mit lediglich einem siebtel der Taktrate arbeitet. Bei diesem Vergleich

muss allerdings berücksichtigt werden, dass die beiden Prozessoren von ganz anderer Ar-

chitektur sind; der Pentium 4 ist mit einem viel größeren Befehlssatz auf Vielseitigkeit aus-

gelegt, der NV40 hingegen ist mit einem sehr eingeschränkten Befehlssatz auf Grafikopera-

tionen spezialisiert. Bei einem modernen Grafikprozessor handelt es sich um einen paralle-

len Streaming-Prozessor, der mehrere Eingabeströme mit der gleichen Operation (auch als

2.1 Einbindung in die Computerarchitektur

Abbildung 2.1: Einbindung der GPU in moderne Rechnerarchitekturen [FHWZ04]

Kernel bezeichnet) verarbeitet. Diese Prozessorarchitektur wird auch als SIMD Architektur

(Single Instruction Multiple Data) bezeichnet. Dies kann der Pentium 4 nicht leisten, er ist im

Allgemeinen dafür ausgelegt einen Eingabestrom zu verarbeiten (SISD Architektur - Single

Instruction Single Data)

In den nachfolgenden Unterkapiteln werden der Aufbau und die Arbeitsweise von aktuel-

len Grafikkarten mit 3D-Beschleunigung erläutert und ihre Funktionsprinzipien dargestellt.

Dabei geht Kapitel 2.1 auf die Einbindung in aktuelle Rechnerarchitekturen ein. Kapitel 2.2

beschreibt die programmierbare Render-Pipeline im Grafikprozessor, welche im Wesentlichen

aus Vertex- und Fragment-Shader besteht.

2.1 Einbindung in die Computerarchitektur

Grafikkarten bestehen im Wesentlichen aus einer GPU und Videospeicher (siehe Abbildung

2.1). Sie sind traditionell über ein Bussystem an den Hauptspeicher eines Computers ange-

koppelt. Das am weitesten verbreitete Bussystem ist derzeit AGP (Accelerated Graphics Port)

[AGP]. Es wird zukünftig voraussichtlich durch PCI-X (PCI Express) [PCI] ersetzt werden.

In der Regel sollen Informationen in den Speicher der Grafikkarte übertragen und ausgegeben

werden. Deshalb ist die Bandbreite des Übertragungskanals in Richtung Grafikkarte deutlich

größer als die des Rückkanals. Insbesondere bei Grafikkarten mit 3D-Beschleunigungsfunktionen

werden zum Teil sehr große Datenmengen aus dem Hauptspeicher in den Videospeicher über-

tragen.

Seit wenigen Jahren besitzen auch Mikroprozessoren in Personalcomputern eine Vektoreinheit, die die selbe

Operation auf einen ganzen Eingabevektor ausführt. Diese Einheiten verfügen allerdings nur über einen sehr

beschränkten Funktionsumfang. Bei Intel heißt diese SSE(2), bei AMD nennt man vergleichbare Techno-

logie 3DNow! und im Motorola/IBM PowerPC Altivec.

2.2 Die Render-Pipeline

Über den Bus werden Texturen zwischen Hauptspeicher und Videospeicher in beide Rich-

tungen ausgetauscht. Eine Textur (lat. textura für Gewebe) bezeichnet im Bereich der Com-

putergrafik ein meist zweidimensionales digitales Bild oder Muster, das die Struktur einer

Oberfläche definiert. Es dient dem Zweck, Objekten wie z.B. Kugeln eine Oberflächenstruk-

tur durch Farbwerte zu geben. Grafikbefehle, Geometrieinformationen und GPU-Programme

werden ausschließlich aus dem Hauptspeicher in den Videospeicher gesendet. Geometrieda-

ten bestehen hauptsächlich aus Vertices. Ein Vertex ist ein Punkt im dreidimensionalen Raum

(siehe Abbildung 2.2 unten). Klassisch wird er durch drei kartesische Koordinaten beschrie-

ben. Die GPU besteht im Wesentlichen aus einer Geometrie- und einer Rasterisierungsein-

heit, auf die noch genauer eingegangen wird. Sind beide programmiert, so spricht man auch

von Vertex- und Pixel-Shader (letzter wird auch Fragment-Shader genannt). Ein Pixel ist das

kleinste Bildelement eines digitalen Bildes, ein Bildpunkt.

Ein Teil des Videospeichers ist für die Informationen vorgesehen, die aktuell auf den Bild-

schirm ausgegeben werden. Der übrige Speicherbereich wird u.a. für Texturen genutzt.

2.2 Die Render-Pipeline

Die Render-Pipeline in Grafikprozessoren besteht aus Funktionseinheiten, die die Eingabein-

formationen Schritt für Schritt in Ausgabeinformationen überführen [RS05]. Wie zuvor er-

wähnt sind das im Groben der Vertex- und der Fragment-Shader. Eine GPU arbeitet daten-

stromorientiert mit einem Eingabe- und einem Ausgabestrom und ist auf Vektor- und Matri-

xoperationen spezialisiert. Ein Datenstrom besteht aus Vektoren, die aus vier Komponenten

zusammengesetzt sind und einen Vertex beschreiben. Die Computergrafik arbeitet bevorzugt

mit dreidimensionalen kartesischen Koordinaten, um einen Punkt im Raum festzulegen. Sie

belegen insgesamt drei Vektorkomponenten. Die vierte Komponente besagt, ob es sich um

einen Vektor oder einen Punkt im affinen Raum handelt.

Es wird eine Szenenbeschreibung in den Grafikprozessor eingegeben, die eine Szene in ei-

nem dreidimensionalen Raum beschreibt. Zur Beschreibung zählen Objekte im Raum, Far-

binformationen und eine Spezifizierung der vorhandenen Lichtquellen. Komplexe Objekte

werden über eine Vielzahl von Primitiven (genauer: Vertices) beschrieben. Primitive sind ein-

fachste graphische Objekte wie Punkte, Linien und Dreiecke, die über Vertices und deren

Attribute definiert sind. Zu den Attributen zählen Farbinformationen und eine zugeordnete

Textur. Jedes komplex geformte Objekt kann so beliebig genau mit endlichem Aufwand ap-

proximiert werden. Ein Fragment ist ein Rasterpunkt eines Primitivs. Nach Durchlaufen der

Pipeline entsteht ein zweidimensionales Rasterbild (Textur), das auf dem Bildschirm ausge-

geben werden kann. Eine Visualisierung dieses Vorgangs ist mit dem Modell eines Hasen in

Abbildung 2.2 oben dargestellt. Der Vertex-Shader erhält eine Szenenbeschreibung in Form

von Vertices (Raumpunkten) und bildet Primitive. Sie werden danach rasterisiert und der

Fragment-Shader berechnet die Farbwerte aller Fragmente. Zum Schluss werden die Frag-

mente in ein Rasterbild überführt. Auf die Funktionsweise der beiden Shader wird in den

nächsten beiden Kapiteln genauer eingegangen.

2.3 Der Vertex-Shader

Abbildung 2.2: Schema der programmierbaren Render-Pipeline einer modernen GPU [RS05]

2.3 Der Vertex-Shader

Der programmierbare Vertex-Shader verarbeitet Vertices, die Primitive wie Linien, Dreiecke

und Polygone beschreiben. Der Shader wendet hauptsächlich Vektor- und Matrixoperationen

auf jeden Raumpunkt an. Dabei werden gleichzeitig Farbinformationen für die Eckpunkte der

Primitive berechnet. Die Kombination beider Operationen ist unter dem Begriff Transform

& Lighting (kurz T&L) bekannt. Der Vertex-Shader wendet Lighting und Shading bei Be-

rechnung der Farbattribute an. Lighting bezeichnet das Beleuchtungsmodell zur Simulation

von Lichtreflexion auf Oberflächen zur Berechnung des Farbwertes eines Punktes. Dazu ist

meist eine Berechnung des Winkels zwischen der Oberflächennormale und der Richtung der

Lichtquelle notwendig (Abbildung 2.4). Weit verbreitete Modelle sind das Phong- und das

Blinn-Modell. Unter Shading versteht man die Anwendung des Beleuchtungsmodells.

Bei der geometrischen Transformation mit Matrixoperationen werden Punktgruppen im

Raum verschoben (Translation), gedreht (Rotation) und vergrößert oder verkleinert (Skalie-

rung), siehe Abbildung 2.3. Mathematisch werden diese Operationen durch Matrixmultiplika-

tionen realisiert, die auf Vektoren von affinen Punkten im Raum angewendet werden.

Der Vertex-Shader berechnet für alle Vertices den Winkel zwischen Oberflächennormale

und Lichtquelle und den Winkel zum Betrachter. Abbildung 2.4 zeigt eine ebene Oberfläche

und die zugehörige Oberflächennormale n. Beispielhaft sind hier die Winkel zwischen Nor-

male und Punktlichtquelle und der Winkel zum Betrachter eingezeichnet. Mit unterschied-

lichen Shading-Varianten lassen sich verschieden modellierte Oberflächen darstellen. Unter

ambientem Shading versteht man eine gleiche Grundhelligkeit für alle Oberflächen unter je-

dem Blickwinkel (siehe Abbildung 2.5 oben). Diffuses Shading berücksichtigt die Richtung

des Lichteinfalls (keine Punktlichtquelle), so dass die Oberfläche unterschiedlich stark re-

2.4 Der Fragment-Shader

Abbildung 2.3: Translation und Rotation von Vertices (Raumpunkten) im Vertex-Shader

[Bee02]

flektiert (siehe Abbildung 2.5 Mitte, in Kombination mit ambientem Shading). Spiegelndes

Shading lässt je nach Materialeigenschaft und Beobachterposition Punktlichtquellen auf der

Oberfläche spiegeln (Abbildung 2.5 unten zeigt alle drei Varianten in Überlagerung).

2.4 Der Fragment-Shader

Die Hauptaufgabe des Fragment-Shaders besteht in der Berechnung von Farbwerten für Frag-

mente. Der Shader erhält als Eingabe bereits rasterisierte Primitive. Dies ist durch das Gitter-

netz über dem Dreieck in Abbildung 2.2 angedeutet. Alle Rasterpunkte werden unabhängig

und einzeln vom Fragment-Shader bearbeitet. Die Farbwerte der Eckpunkte sind bereits über

die gesamte Fläche des Primitivs hinweg interpoliert worden. Der Fragment-Shader erhält u.a.

jeden vorberechneten Farbwert als Eingabe. Oft soll auch eine Textur auf die Fragmente ab-

gebildet werden. In der Regel muss die Textur speziell ausgelesen werden, um sie mit den

Fragmenten verknüpfen zu können. Dazu werden die Texturkoordinaten über die Fragment-

koordinaten interpoliert, so dass sie in den Randbereichen mit den Koordinaten der Fragmente

übereinstimmen. In den übrigen Bereichen können sie nicht mehr exakt zugeordnet werden;

hier muss die Textur gefiltert werden. Filtering bedeutet in diesem Zusammenhang, dass bei

Verkleinerung mehrere benachbarte Originalpixel in nur einen neuen Bildpunkt geeignet über-

führt werden müssen.

Bei Anwendung der Textur kommt Alpha-Blending zum Einsatz. Alpha-Blending bezeich-

net das Übereinanderlegen zweier Bildpunkte, in diesem Fall der Texel und der Fragmente. Ein

Texel bezeichnet das Pixel, d.h. Bildpunkt, einer Textur (Die Abgrenzung von Texeln zu Pixeln

ist manchmal entscheidend). Dabei werden Farben unter Berücksichtigung von Transparenz-

informationen geeignet »gemischt«. Nach Bearbeitung durch den Fragment-Shader kann eine

zweidimensionale Textur gebildet werden.

2.4 Der Fragment-Shader

Abbildung 2.4: Reflexion eines Licht-

strahls an einer Oberfläche [RS05]

Abbildung 2.5: Von o. nach u. additiv: am-

bientes, diffuses und spiegelndes Shading

einer Kugel [RS05]

3 Programmierung von

3D-Grafikkarten

Seit etwa 2001 sind Grafikkarten neben der stark wachsenden Leistungsfähigkeit in zuneh-

mendem Maße programmierbar. Im vorhergehenden Kapitel wurden der Vertex- und der Fragment-

Shader als Hauptbestandteile eines Grafikprozessors eingeführt. Beide Shader sind mit Ma-

schinencode von beschränktem Umfang und mit speziellem, reduziertem Befehlssatz pro-

grammierbar. Die Flexibilität von 3D-Grafikkarten ist dadurch erheblich gesteigert worden.

Es haben sich nicht nur für die Computergrafik, sondern auch für andere Anwendungsfelder

neue Möglichkeiten eröffnet, die sich die Rechenleistung der GPU zu nutze machen.

Die Website http://www.gpgpu.org [GPG] thematisiert die Programmierung von

GPUs und bietet ein öffentliches Forum. Im Forum finden sich oft Referenzen zu Imple-

mentierungen, die für aufwendige Berechnungen ausschließlich auf die Rechenleistung von

Grafikprozessoren zurückgreifen statt auf eine CPU. Beispiele hierfür sind:

Simulationsanwendung: Finite Elemente Simulation [Goe05]

Medizinische Anwendung: Hochauflösende Computertomographie in Echtzeit [XM05]

Allg. wissenschaftlich: Schnelle Fourier Transformationen [MA03]

Ein JPEG2000 Bild-Encoder [WW04]

Die GPU-Programme werden Vertex- bzw. Fragment-Programme genannt, je nachdem für

welchen Shader sie bestimmt sind. Im Allgemeinen ist der Fragment-Shader leistungsfähiger

und flexibler als der Vertex-Shader. Er erlaubt mehr Texturzugriffe und eine bessere Paralleli-

sierung.

In diesem Kapitel soll die Möglichkeit aufgezeigt werden, wie man eine moderne 3D-

Grafikkarte zur Ausführung eigener mathematischer Berechnungen einsetzen kann. Das an-

schließende Unterkapitel beschreibt die Zusammenarbeit der notwendigen Werkzeuge, bevor

diese nachfolgend einzeln erläutert werden. Es werden in den beiden darauf folgenden Unter-

kapiteln die zwei Grafikbibliotheken OpenGL und Direct3D vorgestellt, die den Einsatz von

Vertex- und Fragment-Programmen vollständig unterstützen. Kapitel 3.4 erläutert die flexi-

ble Hochsprache Cg (C for Graphics) [Cg] zur Programmierung beider Shader. Kapitel 3.5

geht auf die Programmierung des Fragment-Shaders ein, insbesondere mit Hinblick auf die

Programmiersprache Cg.

3.1 Zusammenspiel beteiligter Komponenten

3.1 Zusammenspiel beteiligter Komponenten

Für die Ausführung eigener Berechnungen auf modernen 3D-Grafikkarten ist das Zusammen-

spiel mehrerer Komponenten unverzichtbar. Die Kontrolle über alle Vorgänge übernimmt da-

bei eine geeignete Grafikbibliothek wie OpenGL oder Direct3D, die in den Kapiteln 3.2 bzw.

3.3 vorgestellt werden. Der eigentliche Algorithmus wird mit einem oder mehreren Vertex-

und/oder Fragment-Programmen umgesetzt. Für den Bereich des General Purpose Compu-

ting [GPG] wird überwiegend der Fragment-Shader eingesetzt. Die Programmierung der GPU

erfolgt dabei vorzugsweise in einer speziellen Hochsprache wie Cg, es kann aber auch eine

Assemblersprache zum Einsatz kommen.

Eigene Berechnungen laufen nach folgendem Schema ab:

1. Die Eingabedaten befinden sich in einem zweidimensionalen Array im Hauptspeicher.

Die Informationen werden mit Hilfe einer Grafikbibliothek in eine (oder mehrere) Tex-

tur(en) im Videospeicher transferiert. Eine zweite Textur wird für die Ergebnisse im

Grafikspeicher eingerichtet.

2. Das Fragment-Programm wird mit Hilfe der Grafikbibliothek geladen und gebunden.

Liegt ein Cg-Programm im Quelltext vor, dann wird es automatisch mit einem Compiler

in (GPU-)Maschinencode übersetzt. Mit dem Bindevorgang wird es in die GPU geladen

und aktiviert.

3. Die Cg-Bibliothek setzt die Parameter des Shader-Programms. In der Regel wird zumin-

dest eine Referenz auf die Eingabetextur(en) gesetzt, auf die das Programm zugreifen

soll.

4. Die Grafikbibliothek legt die Ausgabetextur (Zieltextur) des Rendervorgangs fest.

5. Es wird ein Computergrafik-Primitiv (oder mehrere) mit Hilfe der Grafikbibliothek ge-

zeichnet. Oft werden Blöcke von mehreren Texturzeilen durch ein Rechteck angegeben.

Die GPU übernimmt die Berechnung aller Zielpunkte und stößt für jeden Texel der

Ausgabetextur das Fragment-Programm an. Die GPU-Programme legen das Render-

Ergebnis fest. Ist kein Shader-Programm aktiv, dann bestimmt die Grafikbibliothek das

Render-Ergebnis (z.B. ein farbiges Rechteck).

6. Sind mehrere Rechendurchläufe (Render Passes) erforderlich und noch nicht abge-

schlossen, wird mit Punkt 2 (oder 3,4) fortgesetzt. Dabei wird die Ausgabetextur mit

ihren Zwischenergebnissen oft als Eingabetextur gebunden bzw. beide vertauscht (Ping-

Pong Rendering).

7. Die zuletzt gültige Zieltextur wird durch die Grafikbibliothek ausgelesen und die Infor-

mationen in den Hauptspeicher transferiert. Das Ergebnis befindet sich dann in einem

Array im Hauptspeicher.

3.2 OpenGL

3.2 OpenGL

Die Open Graphics Library (kurz OpenGL) ist eine Spezifikation [OGL] für ein plattform- und

programmiersprachenunabhängiges API (Application Programming Interface: Schnittstelle

zur Anwendungsprogrammierung für andere Programme) zur Entwicklung von interaktiver,

portabler 2D- und 3D-Computergrafik. Das Interface ermöglicht mit seinen über 250 Funk-

tionsaufrufen komplexe dreidimensionale Szenen darzustellen. OpenGL findet breite Verwen-

dung in den Bereichen CAD (Computer Aided Design), virtuelle Realität, wissenschaftliche

Visualisierung und Videospiele. Für die eigentliche Umsetzung der Grafikoperationen ist der

Grafiktreiber für das verwendete Betriebssystem verantwortlich. OpenGL kann von vielen

Programmiersprachen genutzt werden, u.a. von C, C++ und Java. Die aktuelle Versionsnum-

mer ist OpenGL 2.0.

Ursprünglich von der Firma Silicon Graphics (SGI) entwickelt, legt seit 1992 das Archi-

tecture Review Board (ARB) den Standard fest. Das ARB ist ein Zusammenschluss einiger

führender Firmen aus dem Bereich der Computergrafik. Keine andere Grafikschnittstelle un-

terstützt mehr Plattformen als OpenGL - es läuft unter anderem auf den Betriebssystemen Mac

OS, OS/2, UNIX, Windows 95/98, Windows 2000/NT/Vista, Linux, OPENStep und BeOS.

Der OpenGL-Standard erlaubt Herstellern mittels Extensions (Erweiterungen) neue Funk-

tionalität für OpenGL zur Verfügung zu stellen. Dies ermöglicht es zügig neue Technologie zu

integrieren. Beliebte und zumeist auch sinnvolle Erweiterungen werden oft von anderen Her-

stellern adaptiert und ebenfalls implementiert. Sie werden in diesem Fall oft auch vom ARB

mit in die Spezifikation der nächsten OpenGL Version übernommen. Frame Buffer Objects

[Kur05] sind eine Erweiterung, die vom OpenGL ARB im Januar 2005 verabschiedet wurde.

Sie ermöglicht sogenanntes offscreen rendering, d.h. dass gerenderte Objekte nicht auf den

Bildschirm ausgegeben, sondern in eine Textur im Videospeicher geschrieben werden. Fra-

me Buffer Objects sind für die Implementierung der Aufgabenstellung dieser Diplomarbeit

äußerst hilfreich.

OpenGL 2.0 wird für den Einsatz von Shader-Programmen von den Shader-Sprachen Cg (C

for Graphics) [Cg] und HLSL (High Level Shader Language) voll unterstützt. Mit den Sprach-

bindungen für Cg lassen sich GPU-Programme laden, binden und bei Bedarf aktivieren bzw.

deaktivieren. Es ist möglich Parameter von Shader-Programmen zu setzen und nachträglich

abzuändern.

Algorithmus 1 zeigt ein einfaches OpenGL-Programm in C++. Es zeichnet in einem neu-

en Fenster ein weißes Viereck auf schwarzem Hintergrund. Neben OpenGL werden auch die

Hilfsbibliotheken GLU und GLUT eingebunden, die u.a. eine abstrakte Schnittstelle zur GUI

des Betriebssystems, Tastatur und Maus und viele nützliche Erweiterungen bieten. In der

Hauptfunktion main() wird zunächst GLUT initialisiert, dann eine Größe für das Ausga-

befenster definiert und das Fenster angezeigt. glClearColor() bestimmt die Farbe, mit

der das Fenster im folgenden glClear() Aufruf gelöscht wird. OpenGL arbeitet mit RGB

(Rot-Grün-Blau) Farbdefinitionen. glClearColor() setzt in diesem Beispiel die Lösch-

farbe schwarz, und der Aufruf glColor3f() setzt die Zeichenfarbe weiß. glOrtho()

wählt ein Koordinatensystem, das verwendet wird, und spezifiziert, wie es auf den Bildschirm

abgebildet wird. Mit glBegin() und glEnd() wird ein Grafikprimitiv definiert. In die-

sem Beispiel ist es ein Polygon bestehend aus vier Eckpunkten. Jeder Vertex wird über seine

3.3 Direct3D

x- und y-Koordinate und eine Tiefeninformation beschrieben. glFlush() bewirkt, dass die

vorhergehenden Befehle in Auftrag gegeben und umgesetzt werden.

Algorithmus 1 Einfaches OpenGL-Programm in C++ [Ope]

#include <GL/gl.h>

#include <GL/glu.h>

#include <GL/glut.h>

int main(int argc, char** argv)

{

glutInit(&argc, argv);

glutInitWindowSize (250, 250);

glutCreateWindow (argv[0]);

glClearColor (0.0, 0.0, 0.0, 0.0);

glClear (GL_COLOR_BUFFER_BIT);

glColor3f (1.0, 1.0, 1.0);

glOrtho(0.0, 1.0, 0.0, 1.0, -1.0, 1.0);

glBegin(GL_POLYGON);

glVertex3f (0.25, 0.25, 0.0);

glVertex3f (0.75, 0.25, 0.0);

glVertex3f (0.75, 0.75, 0.0);

glVertex3f (0.25, 0.75, 0.0);

glEnd();

glFlush();

}

3.3 Direct3D

Die Firma Microsoft bietet die Anwendungsschnittstelle DirectX zur Programmierung von

Videospielen für die hauseigenen Betriebssysteme der Windows-Familie an. Direct3D ist die

Komponente von DirectX, die ausschließlich für die Darstellung dreidimensionaler Computer-

grafik vorgesehen ist. Direct3D ist der Vermittler zwischen einem Programm und dem Treiber

der 3D-Grafikkarte. Die meisten erhältlichen Grafikkarten werden mit einem Treiber ausgelie-

fert, der DirectX und damit Direct3D unterstützt. Direct3D ist nicht auf spezielle Grafikkarten

beschränkt, sondern jede Karte, die entsprechende Treiber liefert, kann angesprochen werden.

Die low-level API Direct3D eignet sich für Anwendungen mit hoher Interaktionsrate un-

d/oder Präsentationsfrequenz komplexer grafischer Szenen (wie z.B. bei 3D-Spielen). Bis zur

Version 7 wurde zwischen 2D-Grafik (DirectDraw) und 3D-Grafik (Direct3D) unterschieden.

Nach einer Überarbeitung der Grafikfunktionen wurden beide Teile unter einer einheitlichen

API in Direct3D zusammengefasst.

3.4 Cg - C for Graphics

Vendor A

Cg Runtime

Compiler

OpenGL

DirectX

OpenGL

DirectX

OpenGL

DirectX

Vendor B

Vendor C

GPU

Abbildung 3.1: Anwendungsmöglichkeiten von Cg-Programmen

Die Shader-Sprachen Cg und HLSL unterstützen beide den Einsatz von Shader-Programmen

unter Direct3D.

3.4 Cg - C for Graphics

Cg [Cg] ist eine Abkürzung für »C for Graphics«. Cg ist genau wie die Programmiersprache C

[C] eine Hochsprache, die Details und Interna der gegebenen Hardware abstrahiert und somit

verbirgt. Cg ist syntaktisch und semantisch ähnlich zu C, es ist allerdings zu Zwecken der

Grafikprogrammierung angepasst und abgeändert worden. Alle Schlüsselwörter von C sind

auch in Cg übernommen worden, es finden jedoch nicht alle Verwendung.

Ein Cg-Programm wird mit einem Cg-Compiler in (GPU-)Maschinensprache übersetzt.

Derzeit bietet die Firma NVidia einen Open-Source Cg-Compiler an [CgT04]. Implemen-

tierungen von anderen Herstellern sind aber durchaus ebenso denkbar. Cg hat Sprachbindun-

gen für OpenGL und DirectX. Beide APIs können (auch bereits übersetzte) Cg-Programme

einbinden und verwenden (siehe Abbildung 3.1). Die Programme werden dann von der Lauf-

zeitumgebung in den Programmspeicher der GPU geladen und initiiert. Werden dann Grafiken

mit einer Grafikbibliothek wie OpenGL gerendert, so beeinflussen die Programme in der GPU

die Berechnungen in gewünschter Weise.

Die Unabhängigkeit von Programmen für Grafikprozessoren verschiedener Hersteller wird

durch so genannte Profile realisiert. Für ein Cg-Programm wird vor der Übersetzung und Aus-

führung durch die Laufzeitumgebung genau ein Profil ausgewählt. Jedes Profil schränkt die

Funktionalität von Cg u.a. durch eine maximale Programmlänge, verfügbare Bibliotheks-

funktionen und erlaubte Kontrollstrukturen ein. Auf diese Weise wird garantiert, dass ein

Cg-Programm auf der Zielhardware lauffähig ist. Somit wird deutlich, dass nicht jedes Cg-

Details

Seiten
Erscheinungsform: Originalausgabe
Jahr: 2005
ISBN (eBook): 9783836613101
DOI: 10.3239/9783836613101
Dateigröße: 1.6 MB
Sprache: Deutsch
Institution / Hochschule: Universität Siegen – Elektrotechnik und Informatik
Erscheinungsdatum: 2008 (Mai)
Note: 1,0
Schlagworte: langzahlarithmetik grafikkarte

Autor

Christian Kirbach (Autor:in)

SSL-Beschleunigung mit modernen 3D-Grafikkarten

Zusammenfassung

Leseprobe

Inhaltsverzeichnis

Details

Autor

Christian Kirbach (Autor:in)