Framebuffer-Access bei NV4x

[Corrail]

Hi!

Hab mal eine Frage zur NV4x-Generation und zwar sind rein hardware technisch Framebuffer-Zugriffe im Pixelshader möglich?

[Demirug]

AFAIK nein

[Corrail]

*hm* Schade...
Wie schauts damit eigentlich für DX Next aus? Wird sowas in Betracht gezogen für SM4 oder so?

[Demirug]

Original geschrieben von Corrail
*hm* Schade...
Wie schauts damit eigentlich für DX Next aus? Wird sowas in Betracht gezogen für SM4 oder so?

Ist als Option im Gespräch. Allerdings steht da auch gleich dabei. Nur bei deaktiviertem AA.

S3 hat mal behauptet das der DeltaChrom das Feature haben soll.

[Corrail]

Original geschrieben von Demirug
Ist als Option im Gespräch. Allerdings steht da auch gleich dabei. Nur bei deaktiviertem AA.

Cool, das freut mich wieder :-)
Aber kann man nicht in 2 Buffer rendern? Einen AA-Buffer für den output und einen zweiten, mit dem man dann vergleicht? Oder ist eh so vorgesehen, dass diese Bedingung pro render target / render buffer gilt. Also das man einen AA Buffer und mehrere nicht-AA Buffer verwendet.

[marco42]

Original geschrieben von Corrail
Hi!

Hab mal eine Frage zur NV4x-Generation und zwar sind rein hardware technisch Framebuffer-Zugriffe im Pixelshader möglich?

Der Nachteil dabei liegt ja darin, dass ein vorhergehendes Fragment noch gar nicht im Framebuffer angekommen sein muss. Wenn du das sicher stellen willst, kann es sehr langsam werden. IMHO waere eine prohgrammierbare Blendeinheit eine Loesung fuer manche Probleme.

[Asmodeus]

Wie seht ihr die Chancen, das man unter PCI-Express dann gegenüber AGP genügend Übertragungsleistungen im Rückkanal hat um den Framebuffer wieder in den Speicher auszulesen um dort weiter damit arbeiten zu können. Bis jetzt ist das bei AGP und Nvidia-Karten ja ziemlich mau vom Durchsatz her, bei Ati-Karten kann man es ganz vergessen.

Carsten.

[Corrail]

Wie seht ihr die Chancen, das man unter PCI-Express dann gegenüber AGP genügend Übertragungsleistungen im Rückkanal hat um den Framebuffer wieder in den Speicher auszulesen um dort weiter damit arbeiten zu können. Bis jetzt ist das bei AGP und Nvidia-Karten ja ziemlich mau vom Durchsatz her, bei Ati-Karten kann man es ganz vergessen.


Naja, was ich weiß hat PCI Express theoretisch die gleiche Übertragungsrate in beide Richtungen, also zur Grafikkarte hin und von dort wieder zurück. Bei OGL gibts eine neue Extension (EXT_pixel_buffer_object), Zugriffe auf Grafikkartenspeicher sehr einfach geht. Da übernimmt der Treiber alle Sachen. Wie schnell das allerdings in der Praxis ist weiß ich nicht (sowohl für AGP als auch für PCI Express).


Der Nachteil dabei liegt ja darin, dass ein vorhergehendes Fragment noch gar nicht im Framebuffer angekommen sein muss. Wenn du das sicher stellen willst, kann es sehr langsam werden. IMHO waere eine prohgrammierbare Blendeinheit eine Loesung fuer manche Probleme.


Das stimmt leider. Nur eine programmierbare Blend-Einheit müsste schon viel können. Ich hab mir z.B. folgendes überlegt:
Wenn ich eine Cube-Map rendern will, muss ich alle 6 Seiten einzeln rendern. Nun hab ich mir überlegt, das auf 3 mal zu tun, und zwar immer die gegenüber liegenden Seiten, indem ich bei der z-Koordinate einfach den Absolut-Betrag nehme. Ok, ich bekomm damit Probleme wenn es Primitives gibt, die auf beiden Seiten vorhanden sind. Somit hab ich die Idee verworfen, aber falls es funktioniert hätte, dann brächte ich natürlich 2 Color Buffer und 2 Depth Buffer und müsste selbst Depth-Testing durchführen. Ob das mit einer programmierbaren Blend-Einheit machbar wäre ist fraglich.
Es ist nur ein Beispiel, aber eine programmierbare Blend-Einheit würde vielleicht jetzt einige Probleme lösen, ist aber meiner Meinung nach keine dauerhafte Lösung.