Noch freier programmierbare Grafikpipeline

[hell_bird]

Gibt es eigentlich irgendeine Methode um die Grafikkarte wirklich frei zu programmieren und dabei sich die Grafikpipeline sozusagen selber zusammenzubasteln? Ich meine damit dass man vielleicht eine GPGPU-Sprache als Grundlage nimmt, damit aber auch auf die fixed function Einheiten der Grafikkarte zugreifen kann.

Irgendwie denk ich mir müsste es doch inzwischen möglich sein die volle Kontrolle über alle Einheiten, den Speicher und die Abfolge in der die Berechnungen durchgeführt werden zu übernehmen. nVidia legt ziemlich großen Wert darauf, dass CUDA nicht auf die ROPs zugreifen kann und es auch nicht können wird. Gleichzeitig hört man immer wieder von den Spieleschmieden, dass genau das die Zukunft ist, Unabhängigkeit von OpenGL oder DirectX. Gibt es zur Zeit einen Weg?

[Ihm]

So etwas?
http://alt.3dcenter.org/artikel/2002/05-05_b.php

[AnarchX]

http://www.computerbase.de/bildstrecke/22659/5/

LRB wäre wohl schon ähnlich frei programmierbar gewesen.

[hell_bird]

Ja genau so meinte ich es, wie LRB nur auf derzeitigen GPUs. Vielleicht ist das ja mit aktuellen GPUs noch nicht sinnvoll von der Performance. Vielleicht fehlen auch irgendwelche Features. Weiß man eigentlich was zukünftige GPUs zusätzlich können, außer virtual-memory und preemption. Das sind ja doch eher GPGPU-Sachen.

http://alt.3dcenter.org/artikel/2002/05-05_b.php
ist der P10 eigentlich auf den Markt gekommen? oder war das der erste LRB.

[RLZ]

Gibt es zur Zeit einen Weg?
Es gibt kein öffentlich verfügbares Framework dafür.
Stanford arbeitet zum Beispiel an GRAMPS und auch Nvidias Optix Team hat sowas implementiert.

[Coda]

So etwas?
http://alt.3dcenter.org/artikel/2002/05-05_b.php
Der Chip ist nicht frei programmierbar. Das war nur Marketing. Heutige Chips sind da sehr viel weiter.

Es gibt kein öffentlich verfügbares Framework dafür.
Stanford arbeitet zum Beispiel an GRAMPS und auch Nvidias Optix Team hat sowas implementiert.
Was ich gerne hätte wäre eine Shader-Stage, die die Drawcalls absendet. Dann könnte man beispielsweise direkt auf der GPU Occlusion-Queries auswerten.

Über die normalen Shader ist das aber eher ungünstig zu machen. Da müsste man also wohl einen kleinen Spezialprozessor hinzufügen.

[Partner]

Grafik ist heute nur so schnell weil es problembezogene (renderpipeline z.B.) Hardware gibt. Und das wird sich auch nicht ändern.

Was ich gerne hätte wäre eine Shader-Stage, die die Drawcalls absendet. Dann könnte man beispielsweise direkt auf der GPU Occlusion-Queries auswerten.

Über die normalen Shader ist das aber eher ungünstig zu machen. Da müsste man also wohl einen kleinen Spezialprozessor hinzufügen.Was soll denn das bringen? Es ist bereits jetzt ohne weiteres möglich Objektinstanzen prozedural auf der Grafikkarte zu generieren.

[kunibätt]

Wird wohl ziemlich die CPU und das Bussystem entlasten, wenn man Drawcalls aus dem Shader ausführen könnte.

[Nighthawk13]

Was ich gerne hätte wäre eine Shader-Stage, die die Drawcalls absendet. Dann könnte man beispielsweise direkt auf der GPU Occlusion-Queries auswerten.

Über die normalen Shader ist das aber eher ungünstig zu machen. Da müsste man also wohl einen kleinen Spezialprozessor hinzufügen.

In OpenGL4.1 gibt's Ansätze in der Richtung(gibts vergleichbares auch in Direct3d11?).
2.8.3 DrawElementsIndirect
2.9.8 Indirect Commands in Buffer Objects
http://www.opengl.org/registry/doc/glspec41.core.20100725.withchanges.pdf

Den Drawcall(DrawElementsIndirect) muss man schon noch CPU-seitig starten. Welche Meshes dann gerendert werden steht im command buffer, der GPU-seitig generiert werden kann(Render-to-buffer oder OpenCL).
State changes gehen natürlich nicht zwischen den Meshes.

Langfristig wäre ein kleiner, dedizierter ARM-Core in der GPU schon nett für Kontrollfluss von Drawcall&Statechanges. Ne API dafür müsste aber auch erst noch erfunden werden.

[Coda]

In OpenGL4.1 gibt's Ansätze in der Richtung(gibts vergleichbares auch in Direct3d11?).
2.8.3 DrawElementsIndirect
2.9.8 Indirect Commands in Buffer Objects
http://www.opengl.org/registry/doc/glspec41.core.20100725.withchanges.pdf

Den Drawcall(DrawElementsIndirect) muss man schon noch CPU-seitig starten. Welche Meshes dann gerendert werden steht im command buffer, der GPU-seitig generiert werden kann(Render-to-buffer oder OpenCL).
State changes gehen natürlich nicht zwischen den Meshes.

Langfristig wäre ein kleiner, dedizierter ARM-Core in der GPU schon nett für Kontrollfluss von Drawcall&Statechanges. Ne API dafür müsste aber auch erst noch erfunden werden.
Ja gibt es. Nennt sich DrawIndexedInstancedIndirect.

Ich müsste mal nachschauen ob man die Occlussion Query Results als Buffer bekommt, dann könnte man sogar das damit machen was ich will. Edit: Nö, geht nich.

Was soll denn das bringen? Es ist bereits jetzt ohne weiteres möglich Objektinstanzen prozedural auf der Grafikkarte zu generieren.
Darum ging's aber nicht.

[Nighthawk13]

Speziell zum Thema Occlusion Query scheint's noch was zu geben im Opengl 4.1, Abschnitt 2.16:

void BeginConditionalRender( uint id, enum mode );
void EndConditionalRender( void );

id specifies the name of an occlusion query object whose results are used to determine if the rendering commands are discarded[...]

Ist es das, was du suchst? (bzw. das Direct3D11 äquivalent)

[Coda]

Ja, aber ich glaube das ist aus der D3D11-Spec rausgeflogen. Zumindest habe ich es bisher nicht in der Doku gesehen.
Bullshit, es ist drin. Nur genereller als ich dachte.

Aber das war ja nur ein Beispiel. Das ist wieder Fixed-Function. Programmierbar wär's halt cooler ;)

[kunibätt]

Ist schon hart wenn man als "low-level" Profi hier immer noch hart überboten wird :) Jugngs ihr macht das Forum. Das mein ich ernst. Wenn ihr geht werd, ich auch wieder Luker und widme mich meinem Sega Saturn ;)
Ich fordere der guten Qualität halber nur so "Jungs" wie euch und Love sucks als Bann ;)