@zeckensack usw: PDR problem

[Chris Lux]

ich poste einfach mal den openGL forum link:
http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/010962.html

es geht darum, dass PDR ausser beim bgra format kaum etwas bringt, was ja nicht ganz sinn der sache sein kann.

thx für alle gedanken diesezüglich.

[zeckensack]

Ich habe mit PDR noch überhaupt nicht rumgespielt, und hatte das auch eigentlich nicht vor (nicht portabel, und nicht direkt nötig, um ein gewünschtes Ergebnis zu erzielen).

Ich stimme aber im wesentlichen Adrian zu:The main advantage of PDR is that it enables readpixels to run asynchronously, so you can go and do other things with the cpu while you wait for readpixels to finish.
Vielleicht erwartest du auch einfach zu viel ...
200MB/s ist IMO auch schon ziemlich gut für glReadPixels :kratz2:
Zum Vergleich: glDrawPixels auf meiner Geforce 3 erreicht ~400MB/s, auf der Radeon 9500 Pro ~160MB/s.

[Chris Lux]

200MB/s ist IMO auch schon ziemlich gut für glReadPixels :kratz2:
Zum Vergleich: gl[b]DrawPixels auf meiner Geforce 3 erreicht ~400MB/s, auf der Radeon 9500 Pro ~160MB/s.

wie kommst du bei meinen werten auf 200mb/s, IMO sind das nur ca 120mb/s, was mir wiederum wenig erscheint (kann pci nicht schon 133mb/s?)

[zeckensack]

Original geschrieben von Hans Ohlo
wie kommst du bei meinen werten auf 200mb/s, IMO sind das nur ca 120mb/s, was mir wiederum wenig erscheint (kann pci nicht schon 133mb/s?) =>C:\_Studium\pixperf\PixPerf\Release>pixperf -read -type ubyte -format bgra -size 512 -readpdr
181.323679 copies/sec
47.532916 Mpixels/sec
47.5 MPix/s*4 Byte/Pixel => 190MB/s
Der Rest kam durch großzügiges Runden zustande :D

[Chris Lux]

Original geschrieben von zeckensack
=>
47.5 MPix/s*4 Byte/Pixel => 190MB/s
Der Rest kam durch großzügiges Runden zustande :D

aso, ich ging von dem rgb oder bgr und 40mb/s aus, da sind es dann nur ca 120mb/s. ich finde für das auslesen von 'bildern' aus dem frambuffer mit 3 kanälen weitaus praxisnäher als gerade bgra, weshalb mich das auch wundert, dass genau bgra am besten funktioniert.

[Xmas]

Original geschrieben von Hans Ohlo
aso, ich ging von dem rgb oder bgr und 40mb/s aus, da sind es dann nur ca 120mb/s. ich finde für das auslesen von 'bildern' aus dem frambuffer mit 3 kanälen weitaus praxisnäher als gerade bgra, weshalb mich das auch wundert, dass genau bgra am besten funktioniert.
Der Framebuffer enthält praktisch immer einen Alpha-Kanal (der nur nicht immer genutzt wird). Echte 24bit pro Pixel gab es früher mal bei einigen Karten im 2D-Modus. Heute werden pro Pixel immer 32bit verwendet (abgesehen von FB-Kompression).

[Chris Lux]

Original geschrieben von Xmas
Der Framebuffer enthält praktisch immer einen Alpha-Kanal (der nur nicht immer genutzt wird). Echte 24bit pro Pixel gab es früher mal bei einigen Karten im 2D-Modus. Heute werden pro Pixel immer 32bit verwendet (abgesehen von FB-Kompression).

schon klar, aber wie gesagt geht es um das extrahieren von images, welche durch bildverarbeitungsprozesse verändert wurden. da nützt es wenig einen 'pseudo' alpha kanal mit auszulesen, welcher dann sinnfreie daten für das bild enthält.

das einzige was ich aus dem ganzen lese ist, dass bei nvidia der framebuffer BGRA aufgebaut ist und nicht RGBA ;).

[ScottManDeath]

32 bit = 4 byte = (ein) natives datenformat der x86cpus --> schneller als 3 bytes von den 4 ausmaskieren und diese über den agp bus zu schicken

[Chris Lux]

Original geschrieben von ScottManDeath
32 bit = 4 byte = (ein) natives datenformat der x86cpus --> schneller als 3 bytes von den 4 ausmaskieren und diese über den agp bus zu schicken

nochmal, ich weiss das! mich wundert nur, dass es nur rund 200mb/s sind. ich bin mir nicht mehr sicher wo, aber ich habe gelesen, dass es eben weg von dem max 133mb/s des pci busses (und ja ich weiss, das die karten nicht im pci modus laufen, wurde aber dort als referenz angegeben für speichertranfere über die cpu) mit den extensions durch dma zugriffe (auch auf agp- und lokale grafikspeicherbereiche) der transfer weitaus schneller sein sollte als 200mb/s.

[Chris Lux]

noch ein test, und zwar diesmal das einlesen einer textur aus einer PDR (wieder geht es darum images für eine AR-anwendung so schnell wie möglich zur graka zu bringen):

die ergebnisse zeigen, dass mit PDR es immer (ausser bei BGRA) sehr viel länger dauert die textur zu laden (und IMO sollte dies ein simples memcpy in den graka speicher sein).

512x512 textur:

(gfFX5650go 128mb agp4x)

3 kanäle rgb pdr 170ms nonpdr 3.6ms
3 kanäle bgr pdr 114ms nonpdr 3.6ms
4 kanäle rgba pdr 58ms nonpdr 4.1ms
4 kanäle bgra pdr 1.5ms nonpdr 4.1ms

(gf4Ti4600 128mb agp4x)

3 kanäle rgb pdr 138ms nonpdr 2.0ms
3 kanäle bgr pdr 95ms nonpdr 2.0ms
4 kanäle rgba pdr 49ms nonpdr 2.4ms
4 kanäle bgra pdr 1.2ms nonpdr 2.0ms


dazu kommt, dass wenn man PDR nutzen möchte, und dazu eine library nutzt um
images einzulesen, muss man vorher noch ein memcpy der image daten in die
PDR machen, was zusätzlichen traffic bedeutet. die ergebnisse sprechen für
mich eine deutliche sprache, dass wenn kein BGRA format vorliegt das normale
vorgehen das schnellste ist. ich hoffe, dass ich noch etwas licht in diese
angelegenheit bringen kann (oder arb_pixel_buffer_object bald kommt).

ich weiss was in der pdr spec über die beschleunigten formate steht, aber sollte der pdr versuch nicht wenigstens genauso schnell sein wie der nonpdr?