Memória foglalása a 3D GFX kártyán

Memória foglalása a 3D GFX kártyán
2011-09-13T17:16:57+02:00
2011-09-18T23:15:37+02:00
2022-10-26T04:30:45+02:00
  • Hali!

    Kicsit nagy lett a selftest-el egyutt, ezert inkabb felpakoltam ide: http://het.ath.cx/FastMove/FastMove.htm

    L1 cache kozeleben nagyon zúz, ott nalam 22GB/sec :D

    Még egy FillCharnak tán volna ertelme, plusz egy patch-nak, ami eliranyitja az eredeti fuggvenyeket...
    Mutasd a teljes hozzászólást!
  • Igen, érdekel a gyors memória másoló kód! Ha bemásolnád megköszönném!
    Mutasd a teljes hozzászólást!
  • Jól van na, nincs harag!
    Mutasd a teljes hozzászólást!
  • "Ha nincs igény a részedről rá, akkor miért hiányolod? "

    csak neked akartam segíteni, hogy ennyire ne legyél igénytelen a programozásban...
    Mutasd a teljes hozzászólást!
  • Na még a pinned memory kimaradt: az FSB speeddel megy (nalam 6.8GB/sec) de csak 16mega lehet max (win7:64mega). Es videokartyafuggo, hogy hany ilyen buffered lehet.

    Es a legjobb, hogy nem kell mindenfele Lock/Unlock-al x4rakodni, hanem mintha ráülne valahogy a driver a memoria muveletekre es eszrevetlenul kuldené oda/vissza az adatot a system ram es a vga kozott, de gozom sincs, hogy hogyan mukodik ez technikailag, de lenyeg, hogy mukodik.
    Mutasd a teljes hozzászólást!
  • Kiserletezgettem kicsit ezzel a cpu/gpu memory transferrel.

    Csinaltam egy kis SSE-s masolot a move helyett(ha kell, szolj): Az eppenhogy elerte a 2GByte/sec-et (a sima move, ami ugyanaz, mint a copymemory es 64bit FPU regiszterekkel masol, az 1.36GB/S volt))
    Vegulis egy olvasas+iras(ami lassabb, mint az olvasas) azt' el is fogyott a ram nevleges 6.4GByte/s-e.

    A gpu-bol meg amit ki tudtam csikarni:
    XP, DDR2-800, HD4850: cpu->gpu:2493 gpu->gpu: 25945 gpu->cpu: 1494
    win7_32, DDR3-1066, HD6970: cpu->gpu:2630 gpu->gpu: 65084 gpu->cpu: 2685

    Adatok MByte/sec-ben, 24 darab 16mega meretu texturan voltak a muveletek vegrehajtva asszinkron modban (szoval a driver parositgatott is).

    Csinaltam megegy tesztet, de most 1 nagy 256 megas blokkal:
    2534, 27950, 1590
    2639, 67904, 2700
    Szoval maradt minden kb ugyanannyi, a regi kartya mintha kicsit orulne, hogy nem kell annyit adminisztralnia...

    Ezutan elkezdtem linearis memoriat(ez egy foglalasi mod, a vertex buffer is ilyen linearis, nem 2D, mint egy textura) hasznalni:
    401 709 711
    2743 64321 3269
    A regi hd4850-en iszonyatosan belassult :D (Viszont vertex buffernek pont elegendo ez a sebesseg)
    Az uj kartyan meg ezzel a modszerrrel még kicsit gyorsabb is lett.

    Te programodnal mert sebessegek (upload, download)
    1912 117
    2104 103

    Ez a dx vertex buffer valami brutalis penalty-val bunteti a gpu -> cpu iranyt, szerintem hasznalj inkabb texturat a vb helyett. Abbol tudsz foglalni olyan 256megat is (4k*4k*128bpp).

    De ez tetszik, hogy az uj vga-kon végre már mindkét iranyban ugyanolyan gyorsan kozlekedik az adat a gpu es a cpu kozott es szvsz a system ram sebessege itt a bottleneck.
    Mutasd a teljes hozzászólást!
  • Végre valaki aki mond is valamit.

    Teljesen egyetértek, hogy elég fura eredményeket produkál a program, pontosabban ez az egész project.

    Mindenki beleköt ebbe a szabad memória dologba. Kéremszépen ezt 100%-ban a DirectX report-olja ehhez nekem az ég világon semmi közöm. Úgyhogy ehhez nem tudok mit hozzáfűzni.

    Igen, ez példaprogi végül is azt teszteli, hogy egy Delphi-s program, ami a teljesen általános (Windows.pas) unit CopyMemory() funckióját használja, milyen sebességre képes (sima rendszer illetve GFX memóriával). És ez alapján azt mondhatom, hogy a példaprogram ad egy valós (mindennapi program) sebesség érték eredményt.

    Szerintem nem derült ki, de az én kódom az ég világon semmi forradalmit nem csinál. Mindössze lefoglal egy adott mennyiségű GFX illetve rendszer memóriát és egy tök általános Delphi-s CopyMemory()-t hajt végre lemérve az ehhez szükséges időt. Az egyetlen forradalmi (na jó ez persze túlzás) újdonság, hogy én a vertex buffer-be nem vertex adatokat töltök. Ennyi.

    Az utolsó mondatod nem értem.

    De ha megkérdezhetem, van ötleted arra, hogy W7 alatt miért ad (nálam) a GFX RAM-ból másolás 10x akkora értéket mint XP alatt?
    DirectX verzió függő lehet?
    Mutasd a teljes hozzászólást!
  • HI!

    Nalam elso inditaskor 1GB memoryt reportolt, aztan masodszori inditaskor mar 576MB-t (512MB a valodi). Soval ez a memavail van annyira pontatlan, mint ahogy irjak is róla.

    ToGFP: 1935 FromGPU: 119
    A ketto aranya korrekt, mert 16PCIE lane megy odavele es csak 1 jön visszafele iranyban.
    Viszont ez a 2GB/sec egy picit sovanynak tunik o.O Ha jol tudom, 1 PCIE lane 0.5GByte/sec, akkor 16 lane-nak 8GByte/sec-el kellene zuznia. Azt persze nem tudhatjuk, hogy mit muvel(tököl) a driver pontosan ezzel a bufferrel...

    Egyebkent ezt a 'feladatot' korrektebbul ugy lehetne megoldani, hogy a kozvetlen gpu apival asszinkron memoria muveleteket kezdemenyezel. Akkor nem szamit annyira, hogy milyen lassan vánszorog az adat vissza a gpu-rol a cpu-ra, azzal a dma vezerlo majd ellesz egy darabig, viszont kozben a cpu meg a tiéd.


    copymemory: 1360 (a ram 6.4GB/sec-es)

    Na en valamiert eddig azt hittem (tevesen), hogy ha már d2009 óta a fastMM memory managerjét használja a delphi, akkor áthozák már a gyors move()-t, de ez alapjan a meres alapjan mar nem ugy nez ki :D (upd: es ha jol latom, nincs is fastmove a fastcode challengek kozott o.O)
    Mutasd a teljes hozzászólást!
  • Én igazából arra lennék kiváncsi, hogy van-e ötlete valakinek arra, hogy mire lehetne használni?


    Őszintén? Semmire.

    Az, hogy foglalgatsz, másolgatsz memóriát, senkinek sem kell. A sebesség meg szörnyen pontatlan. Valid és rendesen megírt tesztek ennek a többszörösét mutatják. Szerintem shift + del.
    Mutasd a teljes hozzászólást!
  • Ha nincs igény a részedről rá, akkor miért hiányolod?

    Igaz, hogy a példaprogi egy GFX memória sebesség mérő progi, de a lényeg nem ez, hanem a GFX memória foglaló komponens.
    Én igazából arra lennék kiváncsi, hogy van-e ötlete valakinek arra, hogy mire lehetne használni?

    Megcsináltam úgy, hogy egy listán lehet kezelni a lefoglalt memória chunk-okat és elvileg most már error-prone.

    Mutasd a teljes hozzászólást!
  • "Ez így rendben?"
    rendben, de igény a részemről nincs rá.

    A piacon elég sok kényelmesebb program van GPU memória infóra.

    tudod, legalább annyit tudjon, mint a GPU-z.
    Mutasd a teljes hozzászólást!
  • Nem sokba, de nem gondoltam, hogy ilyen igény lenne...

    Holnapra csinálok egy lista kezelőt hozzá, amivel kezelni lehet a lefoglalt memóriákat. Ez így rendben?
    Mutasd a teljes hozzászólást!
  • akkor ***:

    ha nem sikerül az allokáció, azt se írja ki, hogy sikertelen művelet, ennek ellenére a free-re ott világit az arcodba és ha rányomsz szétszáll.

    miből tartana 1ellenőrzést berakni, hogy az a pointer null-e vagy sem.???

    Mutasd a teljes hozzászólást!
  • Közben eszembe jutott az egyik bug oka! A "Free"-re csak egyszer lehet ráklikkelni, mert egy változó van az "Alloc"-hoz, és amikor ráklikkel a user az "Alloc"-ra, akkor ebbe a változóba kerül a lefoglalt memória osztály mutatója, vagyis a "Free"-vel valójában mindig csak az utolsó "Alloc"-ot lehet felszabadítani.

    A progit igazából így kell használni: elindítod, beírsz egy értéket, klikk "Alloc", utána a 4 sebességmérő gomb (felső utána alsó), amjd kilépés a programból.
    Mutasd a teljes hozzászólást!
  • Köszi, hogy megnézted!
    Nem tudom miért lehet ennyi baja, nagyon egyszerű program, nálam azt leszámítva, hogy furcsa eredmményeket ad (pl. maga a sebességmérés kb 5 sor kód), minden tökéletesen működik XP-n és W7 alatt is. Így távolról nincs ötletem, debugolni kéne, hogy lássam mi a baj.
    Azért köszi!
    Mutasd a teljes hozzászólást!
  • még mindig nem jó:
    alloc size 2048

    Free texture memory: 3,96 GB
    Free texture memory: 3,96 GB
    Free texture memory: 3,96 GB
    Free texture memory: 3,96 GB
    Free texture memory: 3,96 GB
    Free texture memory: 3,96 GB
    Free texture memory: 3,96 GB
    Free texture memory: 3,96 GB
    Free texture memory: 3,96 GB
    Free texture memory: 3,96 GB
    Free texture memory: 3,96 GB

    egyszer sem írt hibát. ennyi memóriám tuti nincs. Ellenben a free access violation dob.

    1.2GB ra jó:
    Free texture memory: 3,96 GB
    Free texture memory: 2,79 GB

    így nem jó a copy to gfx mem meg a copy to ram sem.

    512MB-ra:
    Copy to GFX memory: 512,00 MB 4507 ms (113,605MB/s)
    Copy from GFX memory: 512,00 MB 6312 ms (81,1169MB/s)
    de a copy to/from RAM megint out of mem-et dob.

    256mb-ra:
    Copy to GFX memory: 256,00 MB 1640 ms (156,114MB/s)
    Copy from GFX memory: 256,00 MB 3574 ms (71,6352MB/s)
    Copy to RAM: 256,00 MB 1259 ms (203,328MB/s)
    Copy from RAM: 256,00 MB 134 ms (1916,23MB/s)

    az allocat list index out of bounds-ot ir.

    215mb:
    Copy to GFX memory: 215,00 MB 1191 ms (180,59MB/s)
    Copy from GFX memory: 215,00 MB 2377 ms (90,4532MB/s)
    Copy to RAM: 215,00 MB 648 ms (331,599MB/s)
    Copy from RAM: 215,00 MB 111 ms (1937,64MB/s)
    Mutasd a teljes hozzászólást!
  • Kipróbáltam W7 alatt is, és nem értem az eredményeket.
    A memóriát nem jelzi negatívnak, viszont 1.25GB-ot jelez.
    W7 alatt is úgy tűnik az első memória foglalás nem csökkenti a rendszer memóriát, viszont a továbbiakra sem emelkedik a feladatkezelőben a grafikon, de a commit igen.

    És az eredmények amik számomra rejtélyesek:

    Free texture memory: 1.24 GB
    Free texture memory: 1.03 GB
    Copy to GFX memory: 215.00 MB 377 ms (569.887MB/s)
    Copy from GFX memory: 215.00 MB 2024 ms (106.249MB/s)
    Copy to RAM: 215.00 MB 186 ms (1154.6MB/s)
    Copy from RAM: 215.00 MB 153 ms (1403.88MB/s)
    Mutasd a teljes hozzászólást!
  • Én is ilyesmire gyanakodtam, de szerintem nem ez a hiba.
    Az uint az unsigned integer, ami 32 bites. A Delphi-ben a Longword unsigned és 32 bites.
    Az egyetlen különbség, hogy a Windows a $FFFFFFFF-es értéket -1-ként kezeli (Reading C code in Win32 API).


    There is no Delphi variable type that is the equivalent of a C code Unsigned Integer, UINT. A C code UINT can have a Cardinal value from 0 to 4,294,967,294 AND a single negative value of -1. Delphi declares a UINT as a LongWord (Cardinal), but if this variable has a Value of (hex) $FFFFFFFF (const MAXDWORD), then it is a -1 to the Windows System.
    UINT is defined in C as type unsigned int. Microsoft defines the constant UINT_MAX as 4,294,967,295, which doesn't leave any room for a -1 value. The reasons Microsoft uses -1 are probably two-fold: First, the C compiler won't care about overflow or underflow on unsigned types, and second, "-1" is easier to write than "4294967295" or "0xffffffff", especially when the actual size of the variable isn't known or is liable to change. "-1" means all-bits-one regardless of the variable's size, whereas 4294967295 won't be the proper value for a 64-bit type.


    Ha ezzel lenne a gond, hogy pl. signed lenne Delphi-ben, akkor is 2GB-ig helyesen kellene, hogy jelezze az értékeket, de javítsatok ki ha tévedek!

    Felmásoltam az új verziót, lehet tesztelni és összevetni a GFX és a RAM irási/olvasási sebességét. Nálam ez az eredmény:

    Free texture memory: 917.00 MB
    Free texture memory: 702.00 MB
    Copy to GFX memory: 215.00 MB 179 ms (1203.98MB/s)
    Copy from GFX memory: 215.00 MB 25189 ms (8.53535MB/s)
    Copy to RAM: 215.00 MB 297 ms (723.658MB/s)
    Copy from RAM: 215.00 MB 188 ms (1142.51MB/s)
    Free texture memory: 917.00 MB

    Vagyis a GFX RAM-ba írás gyorsabbnak tűnik, mint a sima RAM-ba, viszont az olvasás borzasztóan lassú. Ennek elvileg így is kell lennie.
    Hát így végeredményben nem sok értelme van ennek, mert egy SSD-ről nagyságrendekkel gyorsabban lehet olvasni.

    Ha másra nem is jó egy kis grafikus/sima memória sebességmérő lett belőle.
    Mutasd a teljes hozzászólást!
  • valószinüleg a .pas-ra portolt igénytelenségben van a hiba

    IDirect3DDevice9::GetAvailableTextureMem method (Windows)

    itt uint és nem long meg egyéb található.
    Mutasd a teljes hozzászólást!
  • A teljes forráskód ott van a .zip-ben, de akkor idemásolom:

    function TGFXMemoryDirect3D9.AllocateMemory(Size: Integer): Pointer; var PGFXMemory: Pointer; Error: HResult; begin Result := nil; if g_pd3dDevice = nil then Exit; Inc(Count); SetLength(VertexBuffers, Count); Error := g_pd3dDevice.CreateVertexBuffer(Size, 0, 0, D3DPOOL_DEFAULT, VertexBuffers[Count - 1], nil); if Failed(Error) then begin if NOT SuppressErrors then begin raise Exception.Create('Error: CreateVertexBuffer.'); end; Exit; end; Error := VertexBuffers[Count - 1].Lock(0, Size, PGFXMemory, 0); if Failed(Error) then begin if NOT SuppressErrors then begin raise Exception.Create('Error: VertexBuffer.Lock.'); end; Exit; end; Result := PGFXMemory; end;

    Nálam tökéletesen működik. Egyébként nálatok (ahol - memóriát ír) amikor ráklikkeltek az Allocate-ra, akkor dob egy ablakot, hogy (amint fentebb is látható): 'Error: VertexBuffer.Lock.'? Mert ha nem akkor sikeres volt a memória foglalás!

    A szabad memória lekérése, nagyon egyszerű:

    function TGFXMemoryDirect3D9.MemoryAvailable: LongWord; begin Result := g_pd3dDevice.GetAvailableTextureMem; end;

    Nem nagyon értem mitől lehet ez a mínusz dolog... Először arra gondoltam valahol előjeles bug van, de nem. De érdekelne, hogy valaki megmondja-e mitől van?

    Azóta végeztem egy sebességmérést is és úgy tűnik (egy 200MB-os file-lal), hogy a GFX RAM-be feltöltés mintha még gyorsabb is lenne mint sima RAM-ba (igaz elhanyagolható különbséggel). Viszont az olvasás jóval lassabb.

    Majd még fejlesztgetem és felrakom a legfrissebb verziót.
    Addig kiváncsian várom a választ, hogy van-e az említett dialog nálatok, és hogy mitől lehet ez a negatív szabad memória kijelzés?

    Egyébként milyen OPrendszeren néztétek? Nálam WinXP Pro SP3 van, de majd megnézem W7 alatt is.
    Mutasd a teljes hozzászólást!
  • TGFXMemoryDirect3D9 V0.1.1.2 ˆ 3delite 2011 - 3delite's software
    Free texture memory: -35651584 Byte
    Free texture memory: -261095424 Byte
    Free texture memory: -486539264 Byte
    Free texture memory: -711983104 Byte
    Free texture memory: -937426944 Byte
    Free texture memory: -1162870784 Byte
    Free texture memory: -1388314624 Byte

    Mivel foglalsz memóriát, és hogyan kérdezed le? Másold be légyszi, mert szerintem valamit félreértesz.

    (1.5 giga mem van a kártyámon)
    Mutasd a teljes hozzászólást!
  • Ezt most nem igazán értem.

    Azt mondod, hogy - értékeket ad a szabad memória lekérdezéskor?
    Ezt teljesen a Direct3D9 funkciója, én csak lekérem ezt az értéket.
    Mutasd a teljes hozzászólást!
  • nem jó:

    Free texture memory: -45088768 Byte
    utána:
    Free texture memory: -270532608 Byte
    utána:
    Free texture memory: -495976448 Byte

    1GB ra:
    Free texture memory: -1118830592 Byte

    1.5GB-ra nem jó.
    Mutasd a teljes hozzászólást!
  • Hi!

    Írtam egy egyszerű Delphi komponenst ami a grafikus kártya memóriáját tudja használni.
    Tudom, tudom, erre CUDA való meg hasonlók, csak kiváncsi voltam meg lehet-e egyszerűen valósítani, amolyan barkács módon.

    Ha van kedvetek kipróbálni itt letölthető: TGFXMemoryDirect3D9

    Sima vertex buffer-t használ (barkács megoldás de talán annyi előnye lehet, hogy bármilyen DirectX-es grafikus kártyával működik).

    Az eredmény nem valami jó, de leírom nálam hogy működik.
    A kártya amivel teszteltem egy GF9800GT 512MB RAM-mal. A szabad textúra memóriát tudom lekérni. Amikor elindul a program akkor kb. 1GB szabad memóriát jelez. Első alkalommal 215MB-ra tudtam feltornázni az értéket amit még képes alloc-álni. Ha utána megpróbálok mégegyszer alloc-álni, akkor a szabad textúra memória az alloc-ált memória 2x-esével kevesebbet jelez és ha jól láttam ugyanennyi levonódik a rendes rendszer memóriából is.
    De első alkalommal simán lehet 215MB-ot kapni úgy, hogy a rendszer memória nem csökken!

    Ha van kedvetek nézzétek meg a példa programot.
    Több MB-os adattal még nem teszteltem, de teszt képpen foglal egy kis memóriát, bemásol egy szöveget, aztán kiolvassa és megjeleníti. Szóval az elmélet nagyjából működőképes.
    Kiváncsi lennék ha van valaki, aki 1 vagy több GB-os grafikus kártyával rendelkezik, milyen eredményeket kap?

    Érdemes a progi futása közben egy feladatkezelőt is indítani és megfigyelni a rendszer memória változásait.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd