Grafikspeicher bremst?

TS1234

Hallo,

also ich wollte einen Speicherblock aus VRAM nach SYSRAM kopieren
(256x256x32bit). Das dauert aber sehr lange ~30 msek. Aber wenn ich von SYSRAM nach VRAM kopiere, dann dauert es nur 1 msek. Ich weiß nur nicht weshalb das so ist - oder was ich falsch mache... Oder gibt es einen Trick?

Ich habe nur die 2 Speicheradressen ermittelt und halt kopiert... Generell der Lesezugriff auf VRAM ist schleppendlangsam... Scheinbar soll da nur Grafikkarte zugreifen...

Cpp_Junky

Was hast du denn für ne Grafikkarte ?

illuminator

Das Problem hatte ich auch mal, genau genommen hab ichs immer noch (hatte ja kein Lösung dafür, weils denke ich keine gibt)

Ich wusste aber mal eine Erklärung für das Problem, dass man ins VRAM zwar schnell schreiben kann, aber nur langsam lesen.
Irgendwie ist Grafikkarten RAM besonders fürs schreiben optimiert.

TS1234

Eine alte ATI xpert 2000 - auf anderen PC's gibts aber keinen großen unterschied...

Hier ein Ausschnitt

for (i=0;i<count;i++)
  {
    rgb1=buffer1[i];
    r1=((rgb1 >> 16) & 0xFF);
    g1=((rgb1 >> 8) & 0xFF);
    b1=(rgb1 & 0xFF);

    rgb2=buffer2[i];
    r2=((rgb2 >> 16) & 0xFF);
    g2=((rgb2 >> 8) & 0xFF);
    b2=(rgb2 & 0xFF);

    r3=(r1+r2)/2;
    g3=(g1+g2)/2;
    b3=(b1+b2)/2;
    rgb3=(r3 << 16) + (g3 << 8) + b3;
    buffer2[i]=rgb3;
  };

dabei bremst der lesezugriff erheblich - kommentiere ich die Zeilen unten aus, dann ist es um Faktor 50 schneller:

rgb1=buffer1[i];
rgb2=buffer2[i];

TS1234

@illuminator

VRAM ist normalerweise schneller als RAM
Lesezugriff ist normalerweise schneller als Speicherzugriff

Es hängt entweder an Windows - oder an Grafikkarte - einerseits ist es ja verständlich - Grafikkarte hängt irgendwo weit von anderer Hardware entfernt - und bis man Zugriff hat, kann es schon bisschen dauern - allerdings erklärt es nicht den großen Unterschied zw. Lesen/Schreiben.

Da sind mir die alten DOS-Zeiten lieber wo das noch "schnell" ging

illuminator

http://www.c-plusplus.net/forum/viewtopic.php?p=344867&highlight=#344867

TS1234

EDIT

Bei den Speichern wunden einige Tricks angewendet - im in Voraussicht, dass man öfter auf Speicher schreiben, als lesen muss (stimmt ja wohl auch)

Im Gegensatz zu DRAM, das fuer viele Zwecke verwendet wird, sind VRAM
Bausteine ausschliesslich auf (hochwertigen) Grafikkarten zu finden. Ihr
wesentlicher Unterschied ist, dass sie gleichzeitig gelesen und
beschrieben werden koennen ('Dual ported', Sie besitzen zwei getrennte
Adress- und Datenbusse). Dadurch kann man bei Grafikbeschleunigerkarten
hohe Bildwiederholfrequenzen (hohe Auslesebandbreite fuer den
Bildaufbau) und hohe Geschwindigkeit (hohe Bandbreite beim Schreiben in
den Grafikspeicher) kombinieren.

TGGC

Hast du eigentlich noch den Abschnitt nach dem von Dir fett markierten gelesen?

TS1234

So - neue Erkenntniss!

Habe festgestellt, dass sowohl schreiben als auch lesen etwa gleich schnell ist. Jedoch kann die Grafikkarte nicht zw. diesen beiden Zuständen switchen. Wenn man wie für Transparenz notwendig 2 pixel ausliest und dann 1 pixel einzeichnet, dann bremst es erheblich ab. Dabei gibt es keinen Unterschied, ob man nur aus vram liest und dann in sysram schreibt - es ist immer langsam...

habe sogar einen test gemacht - lesen aus videoram + berechnete farbe in eine variable speichern - das ist höllisch schnell (2 msek für 256x256). Wenn man in ein Int array[2] schreibt, dann gibt es auch keine Unterschiede, aber schon ab array[3] gibt es wieder diesen speedeinbruch...

FAZIT: Das wurde mit Absicht gemacht - anders kann ich es mir nicht erklären...

TGGC

*LOL*

Klar wurde das mit Absicht gemacht. Oder wäre es dir lieber, wenn das reine Schreiben oder Lesen langsamer wäre, nur damit du keinen Geschwindigkeitsunterschied hast?

Bye, TGGC

TS1234

Nein du hast es nicht verstanden...

Nur Lesen ist schnell
Nur Schreiben ist schnell
Lesen+Schreiben laaaaaaaaaangsam
Es ist dabei völlig egal in welches Buffer ich schreibe.

Wenn ich in Variable schreibe - dann ist es schnell
Wenn ich in int array[2] schreibe - dann ist es auch schnell
Wenn ich in int array[3] (oder mehr) schreibe - dann ist es wieder laaaaaaaaaaaaangsam

Scheinbar muss der Speicher irg. umschalten Vram/Sysram und intern gibt es wohl richtige Kopierorgien... Darum habe ich es seingelassen - Lesen aus SYSRAM - und schreiben ins VRAM - so ist es bisher am schnellsten... ca. 10msek

Typisch PC - da haben die sich mal wieder was ausgedacht... :xmas1:

PEACE

TGGC

TS1234 schrieb:

Nein du hast es nicht verstanden...

Na wenn du es sagst. Kannst du mir bitte auch noch mitteilen, was genau ich nicht verstehe? Kannst ja solange auch mal nach dem Stichworten wie "Cache" googeln. *pfeif*

Und ehrlich gesagt, ich verstehe nicht wo dein Problem ist? Was hast du dagegen, das lineares Lesen und Schreiben durch spezielle Tricks beschleunigt wird?

BTW: Früheren Unsinn wegeditieren kommt immer gut.

Bye, TGGC

rapso

TS1234 schrieb:

Wenn ich in Variable schreibe - dann ist es schnell
Wenn ich in int array[2] schreibe - dann ist es auch schnell
Wenn ich in int array[3] (oder mehr) schreibe - dann ist es wieder laaaaaaaaaaaaangsam

und du bist dir sicher dass das alles was du glaubst dass der code macht nicht vom compiler wegeditiert wird? mein compiler löst eine schleife auf bei der nur der letzte durchlauf für das ergebnis in einer variable wichtig ist... deiner nicht?

zudem hast du noch nicht geschrieben wie das alles abläuft, denn einige dinge passieren vielleicht im hintergrund die du nicht in deine messungen einbeziehst? z.b. wenn du den vram speicher lockst, dann wartet deine cpu bis die graka ein "ok" meldet, wenn du da schon am messen bist, dann ist die messung verfälscht. es könnte auch sein dass du deine textur mehrmals lockst bevor du sie nutzt, dann wird auch einiges wegoptimiert (vielleicht).

rapso->greets();

TS1234

ich benutze GCC - da ist sicher nicht der schnellste compiler für windows - das ist noch so ein Arbeitstier... Arbeitet Schleifen normal ab...

ich locke gar nix - muss ich was locken??? Habe keinen Unterschied festgestellt - egal ob ich es mache oder nicht. Ich habe nur die 3 Buffer - und ich lese werte aus buffer 1+2 aus und schreibe in buffer 3.... Oder muss ich für jeden Zugriff buffer locken/unlocken?

Wenn ich was falsch mache, dann sagt es bitte...

...
int dummybuffer[2]; //nur so test

for (i=0;i<count;i++) 
  { 
    rgb1=buffer1[i]; 
    r1=((rgb1 >> 16) & 0xFF); 
    g1=((rgb1 >> 8) & 0xFF); 
    b1=(rgb1 & 0xFF); 

    rgb2=buffer2[i]; 
    r2=((rgb2 >> 16) & 0xFF); 
    g2=((rgb2 >> 8) & 0xFF); 
    b2=(rgb2 & 0xFF); 

    r3=(r1+r2)/2; 
    g3=(g1+g2)/2; 
    b3=(b1+b2)/2; 
    rgb3=(r3 << 16) + (g3 << 8) + b3; 
    dummybuffer[0]=rgb3; //nur so zum spaß - ist noch schnell
  };
...

wenn das dummybuffer-array eine größe von bis zu 2 hat - dann ist es immer noch schnell - ab einer größe von 3 wird es sofort katastrophal - dabei mache ich doch nix mit dem dummybuffer - weder kopiere ich es, noch verschiebe ist es - noch sonstwas

buffer1+buffer2 sind vram-videobuffer - die adressen übergebe ich der dll

Und das mit Chache klappt nicht. egal wie oft ich ins buffer/array schreibe - sei es 1x pro dll oder 10000 pro dll - es gibt kein unterschied - wenn ich es ganz entferne - dann wird es schnell wie rakete...

TGGC

Also ich verstehe dein Problem immer noch nicht, was möchtest du denn noch erreichen? Das der Speicherzugriff der Bottleneck ist, hast du ja offensichtlich schon festgestellt.

Bye, TGGC

TS1234

Nein der Speicherzugriff ist gut - solange man nicht abwechselnd schreibt/list (was für Transparenz ja unerlässlich ist) - Darum schreibe ich nur ins vram und lese von sysram (andersrum geht nicht!!!!). Da soll man blos die Logik finden weshalb eines besser als das andere funktioniert...

rapso

mein compiler würde sowas daraus machen:

...
int dummybuffer[2]; //nur so test

    rgb1=buffer1[count-1]; 
    r1=((rgb1 >> 16) & 0xFF); 
    g1=((rgb1 >> 8) & 0xFF); 
    b1=(rgb1 & 0xFF); 

    rgb2=buffer2[count-1]; 
    r2=((rgb2 >> 16) & 0xFF); 
    g2=((rgb2 >> 8) & 0xFF); 
    b2=(rgb2 & 0xFF); 

    r3=(r1+r2)/2; 
    g3=(g1+g2)/2; 
    b3=(b1+b2)/2; 
    rgb3=(r3 << 16) + (g3 << 8) + b3; 
    dummybuffer[0]=rgb3; //nur so zum spaß - ist noch schnell
  };
...

und da würde ich mich nicht wundern wenn es schnell ist...

will dir damit nur sagen, das ist c und kein assembler, du weißt nicht was der compiler daraus wirklich macht und wenn du benchmarks erstellst und jedesmal einen anderen code hast, dann kannst du nicht 100%ig behaupten es lege am spiecher ohne dir das assemblat anzuschauen... das müßtest du dir mit gcc eigentlich ausgeben lassen können.

aber wenn du jedes frame in grafikkarten buffern fummelst, dann wirst du eh nicht wirklich performance bekommen. wenn es geht sollte man da bessere wege finden.

rapso->greets();

TGGC

Also sind jetzt alle Fragen geklärt?

Bye, TGGC

TS1234

will dir damit nur sagen, das ist c und kein assembler, du weißt nicht was der compiler daraus wirklich macht und wenn du benchmarks erstellst und jedesmal einen anderen code hast, dann kannst du nicht 100%ig behaupten es lege am spiecher ohne dir das assemblat anzuschauen...

Klar, wenn ich z.B. alle Werte in 1 Variable speicher, dann kann theoretisch der Compiler die FOR-Schleife einfach rausoptimieren - macht der aber nicht da die Geschw. bei dummyarray[2] und dammyarray[3] gleich wäre... Zudem habe ich keine kostante Werte (woher soll der Compiler wissen wie breit/hoch das jedes mal ist?) ASM kann ich nicht...

aber wenn du jedes frame in grafikkarten buffern fummelst, dann wirst du eh nicht wirklich performance bekommen. wenn es geht sollte man da bessere wege finden.

O_o also soll ich garnicht mehr in grafikbuffer fummeln?

Also sind jetzt alle Fragen geklärt?

Naja ich gebe am besten einfach auf... Sind wohl höhere Mächte am Werk...

TGGC

TS1234 schrieb:

O_o also soll ich garnicht mehr in grafikbuffer fummeln?

Richtig.