4. Grafikspeicher bremst?

Grafikspeicher bremst?

  • I

    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.

    0
  • T

    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];

    0
  • T

    @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

    0
  • I

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

    0
  • T

    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.

    0

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

    0
  • T

    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...

    0

  • *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

    0
  • T

    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

    0

  • 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

    0
  • R
    Mod

    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();

    0
  • T

    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...

    0

  • 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

    0
  • T

    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...

    0
  • R
    Mod

    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();

    0

  • Also sind jetzt alle Fragen geklärt?

    Bye, TGGC

    0
  • T

    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...

    0

  • TS1234 schrieb:

    O_o also soll ich garnicht mehr in grafikbuffer fummeln?

    Richtig.

    0
  • T

    Ja - aber wie soll ich dann pixel lesen/schreiben???

    0

  • Nur mit der GPU, die CPU ist für sowas nunmal nicht geeignet.

    Bye, TGGC

    0
Anmelden zum Antworten