CUSTOM MEMORY ALLOCATOR???

Per qualsiasi tipo di problema a livello software hardware o randomware postate qua
armaricc
Specialist
Specialist
Messaggi: 440
Iscritto il: lun apr 04, 2011 8:18 pm

ho visto che in un sacco di forum parlano di questo nuovo parametro che con la patch 1.60 può essere utilizzato qualcuno ci ha capito qualcosa?? ???
qui http://community.bistudio.com/wiki/ArmA ... _Allocator ho letto un pò di cose ma non c'ho capito una mazza  :o

altra cosa sul sito degli HH dicono di modificare 2 parametri in  ARMA2OA.config esattamente AToC=7 e
FXAA=12;
Ultima modifica di armaricc il lun gen 02, 2012 2:42 pm, modificato 1 volta in totale.
[align=center]Immagine[/align]
Crotalus
Corporal
Corporal
Messaggi: 798
Iscritto il: mar mar 01, 2011 10:24 pm
Località: Granze (PD)

L'ATOC, se non ricordo male, è quel parametro che in passato la BI aveva "taroccato", per rendere meno dettagliati gli oggetti a lunga distanza. Se ci avete fatto caso, con la nuova patch, anche a breve distanza le ruote dei carri, ad esempio, appaiono a quadrettoni, ciò permette di aumentare i frames, e credo sia la causa, buona, per migliorare la fluidità del gioco. Non c'è nulla da fare cari miei, arma è un gioc esigente in termini grafici, con la patch precedente c'erano vistosi cali di frames in alcune occasioni, ora le cose vanno meglio, la coperta è sempre quella, se la tiri da una parte perdi qualcosa dall'altra, non si può avere tutto, hanno cercato più che altro di bilanciare il carico grafico per tutti. Facendo così anche chi si avvicina a questo mondo per la prima volta non si sete spaesato di fronte alla necessità di cavarci qualcosa a livello grafico da questo gioco, abituati alcuni agli scorci visibili su BF3, ad esempio. Non ho visto BF dal vivo, ma credo si sogni tutta questa mole di poligoni, il counter poligonale secondo me è più basso. Come dicevo l'atoc modificato genera, se attivate l'antialiasing, ancora quell'effetto strano sui ciuffi dei cespugli, piante ed erba in generale. L'FXAA invece "dovrebbe" fare ciò che fa il programmino per migliorare la grafica che vi ho postato, mi sembrava di aver capito che non fosse ancora abilitato in questa patch, dovrbbe divenire un parametro configurabile dalle opzioni video, ma non ne sono sicuro, non seguo molto il forum dei bohemia. :P
Per il custom, credo lavori da se in background, se avete notato nella root di arma c'è una cartella con delle dll, ma dal file che c'è dentro poco si capisce, forse trattandosi di editing Giallustio ci capisce di più. :P ;)
Immagine
Crotalus
Corporal
Corporal
Messaggi: 798
Iscritto il: mar mar 01, 2011 10:24 pm
Località: Granze (PD)

Provato orora l'FXAA. Fenomenale, attivatelo ragazzi, è meglio dell'antialiasing originale del gioco, in abbinata col nuovo preset grafico che vi ho postato nella sezione mod, è tutto molto più chic. Spariscono le scalettature dagli oggetti a breve e lunga distanza, le prestazioni a quanto pare non ne risentono. L'ATOC messso a 0 invece, previene il formarsi di quegli artefatti di cui parlavo sopra, per il resto non noto nulla di diverso, si vede che hanno lavorato su altri parametri per ottimizzare il gioco. :D
Immagine
Giallustio
Colonel
Colonel
Messaggi: 2253
Iscritto il: dom feb 27, 2011 1:43 pm
Località: Genova

Domani sera poi mi spieghi tutto prima del training ;D
[align=center]Volere è potere[/align]
Crotalus
Corporal
Corporal
Messaggi: 798
Iscritto il: mar mar 01, 2011 10:24 pm
Località: Granze (PD)

Presa dal sito HH questa forse è la soluzione adottata nel gioco, o che adotteranno, in quanto mi risulta che la patch 1.11 di Arma sia già uscita e l'ho installata.

The quest for the best memory handling is finally over?

Virtual Address Space Problems

Ever since ArmA was published, one of the biggest problems with stability and compatibility was caused by virtual address space exhaustion. The problem is the game needs to store a lot of data, using a lot of virtual addresses, and at the same time a large amount of virtual address space are used by other parts of the system, most notable of them being the graphics card driver. The problem started even before ArmA was published, back in the times of Operation Flashpoint, when the first graphics cards with 256 MB RAM or more appeared. Flashpoint was often even less stable than ArmA on the same system, and the reason is that it used memory mapping as a way to access files. While being fast and easy to use, memory mapping uses huge amounts of virtual space. As a workaround we provided a way to access files without mapping them (the well known -nomap command line). For ArmA we redesigned file access completely, not using file mapping at all, but using normal file API instead. At the same time we switched to Overlapped I/O, so that we can load the textures and other resources in the background. We (and you) learned the hard way that this was not enough.
Memory

Sky's the Limit?

Now what happens is that each application is given 2 GB of address space by the operating system. 2 GB sounds somewhat limiting, however it's not that bad - few people have more RAM in their computers anyway. Now the important thing to note is we are not talking about RAM (physical memory) here, we are talking about the address space. The application is limited to 2 GB address space, so if your system has 512 MB RAM or 4 GB - it does not matter here at all.

Those 2 GB are used for everything the application needs. Recent graphics cards drivers often eat several hundred of MB from this. To make it even worse, there are some system components which do not eat big parts, but eat them here and there, making the space fragmented into multiple small regions. My experience shows it is almost impossible for the game code to allocate more than around 700-900 MB of virtual space without the system becoming extremely unstable - and we are not talking one big contiguous allocation here, but rather several 10-100 MB sized chunks. To make it a nightmare, driver programmers seem not to have noticed the fact the address space is a limited resource, and the drivers often do not handle virtual allocation failure well. This mean once a game allocates too much of the virtual space, very strange things start to happen, like a triangle mess on the screen, or sometimes even a system reboot.


The Future - 64 bits


In the long term, the solution to this will be to move to a 64 bit operating system and to compile the game as a 64 bit application. Such a solution is not realistically possible for ArmA, partly because not enough people use a 64b OS yet, partly because the change is too big and would take too much time and resources.

We have performed various experiments and optimizations with mixed results in several patches (see this forum topic, or this into the new forum) , but none of them worked really well, with every solution either the performance or the stability suffered on some systems. Meanwhile, as we were continuing ArmA 2 development, we needed to allocate even more textures and more memory, and we were becoming more and more limited by this, up to a point where the game was not able to run stable on many systems at all .


Memory with No Address


And then one day, an idea came, as such ideas usually do, from nowhere. As usual with such ideas, once the system is implemented, it seems very obvious, but I never heard about it being used before, therefore I am quite proud to have invented it. I call this technique Non-addressable Memory Store.

The technique is based on using the File Mapping API. Yes, you hear well, the same API which caused problems with Flashpoint, but this time it is used a very different way, using it not to read the files, but as a way to allocate memory:

on game initialization, enough memory is reserved and committed by using CreateFileMapping API. This consumes the physical memory, but no virtual addresses
when storing or retrieving a page of data, temporary view is created using MapViewOfFile, which is destroyed again once access is finished. This uses very little of the virtual space (64 KB). Typically only a few pages are mapped into the memory this way at the same time.

Windows is handling this pattern very well, while the space can be backed up by the "page file" in theory, in practice it works in such a way that as long as there is enough of physical memory available, there is zero page file traffic and all information is handled in the physical memory only. The memory kept in this type of storage is not mapped to any virtual addresses at all, it is identified by the offset in the file mapping instead. Addresses are assigned only temporarily, when the content of the cache is read. This is possible thanks to the fact that the data stored in the file cache are location independent (do not contain any pointers).


The Barrier Is Broken


U.S. Navy Photo by Ensign John Gay This technique in theory allows even for a 32b application to use more memory than 32b address space allows - the size is limited only by the possible size of the file mapping, and by the free RAM, therefore with 32b OS it would be possible to manage about 3 GB of data, and with 64b OS even more. This is of not something we do in ArmA, experiments have shown having a file cache size larger than 512 MB brings very little improvement, as we are not reading that much data anyway, but for some other applications it might be a useful option. It is not limited to file caching, but it can be used to store any content, with one significant limitation - the application must never point into a memory allocated this way using ordinary permanent pointers, as the pointers would become invalid once the memory is unmapped.

What this brings to ArmA is that the internal file cache, which is sized between 100 - 500 MB depending on how much RAM you have in your system (or depending on what -maxmem command line argument you use), is now using almost no virtual space at all. Those several hundreds MBs seem to be enough to keep the rest of the system happy. So far it seems to have fixed the infamous "Cannot allocate system memory surface" on almost all systems we have tested, without having to limit the memory used by the game.


Available to You in the Nearest Patch

This memory handling will be published in the upcoming 1.11 patch, and I hope you will like it as much as I do.

Quell'upcoming non so cosa significhi, forse dopo la patch 1.11? :)
Immagine
armaricc
Specialist
Specialist
Messaggi: 440
Iscritto il: lun apr 04, 2011 8:18 pm

quando sono andato a vedere  i parametri in Ama2 config.  avevo Atoc= a 3 e e FXAA= 0 o messo i valori suggeriti sul sito degli HH e mi sembra molto meglio :D, stasera Cro provero ad abbinarci quel preset grafico che dicevi,
cmq da quando ho messo la patch 1.60 la fluidità di arma mi sembra migliorata notevolmente soprattutto quegli odiosi microscatti mi sembrano quasi spariti ;D
[align=center]Immagine[/align]
Crotalus
Corporal
Corporal
Messaggi: 798
Iscritto il: mar mar 01, 2011 10:24 pm
Località: Granze (PD)

Il valore di ATOC lo hai messo a 0? Io mi ricordo fosse il valore migliore. Per l'altro a 12 va benissimo, scalettature inesistenti, o almeno meno percepibili, senza forzare l'antialiasing da pannello video. ;)
Immagine
armaricc
Specialist
Specialist
Messaggi: 440
Iscritto il: lun apr 04, 2011 8:18 pm

lo ho impostato a 7 seguendo il consiglio  sul sito HH stasera proverò a metterlo a 0 poi ti faccio sapere :)
[align=center]Immagine[/align]
armaricc
Specialist
Specialist
Messaggi: 440
Iscritto il: lun apr 04, 2011 8:18 pm

[quote="Crotalus"]
Il valore di ATOC lo hai messo a 0? Io mi ricordo fosse il valore migliore. Per l'altro a 12 va benissimo, scalettature inesistenti, o almeno meno percepibili, senza forzare l'antialiasing da pannello video. ;)
[/quote]
tempo  fa avevo trovato questo
qua ci stanno tutti i valori di ATOC che in pratica è il livello di copertura Alpha sull'Antialias
questi sono i valori per la standalone (o solo arma2 o solo arrowhead)
0 - disabled
1 - AToC on grass
2 - AToC on new OA trees
4 - AToC on old A2 trees

questi invece sono i valori per la combined (arma2+arrowhead)
3 - AToC on grass & OA trees
5 - AToC on A2 trees + grass
6 - AToC on A2 + OA trees
7 - AToC enabled on grass, A2 & OA trees (default)

per le altre voci vedi qua
http://community.bistudio.com/wiki/arma2.cfg
[align=center]Immagine[/align]
Crotalus
Corporal
Corporal
Messaggi: 798
Iscritto il: mar mar 01, 2011 10:24 pm
Località: Granze (PD)

[quote="armaricc"]
lo ho impostato a 7 seguendo il consiglio  sul sito HH stasera proverò a metterlo a 0 poi ti faccio sapere :)
[/quote]

Che strano, io ce lo avevo già a 7, ma se provi ad impostare l'antialiasing, noterai artefatti a video, prova. Metendolo a zero ciò non si verifica, dovrebbe inoltre riabilitare un certo dettaglio sulle piante a lunga distanza. Sul Chernarus, ad esempio, con atoc a 7 o più, notavi gli alberi lontani come semplici bitmap da gioco pre 2000. :D
Immagine
Crotalus
Corporal
Corporal
Messaggi: 798
Iscritto il: mar mar 01, 2011 10:24 pm
Località: Granze (PD)

Quindi ATOC è attivo se si usa l'antialiasing, ecco il perchè dei difetti a video, molto probabile che alcune schede, tipo AMD, lo gestiscano male. Non è un mio problema dato che non lo uso. L'FXAA funziona solo se è disattivo il postprocessing, ed ha senso visto e considerato che l'effetto di postprocesso maschera i difetti dovuti alle scalettature sugli oggetti. 12 è un valore accettabile per non far calare drasticamente le prestazioni, quasi quasi provo il massimo, 17! :o

Mettiamo un promemoria per gli altri:

FXAA=0 setting not available in UI. Default is Disabled. enables Anti-Aliasing technique via post processing [2]

0 - Disabled
1 - FXAA_QUALITY_PRESET_10
2 - FXAA_QUALITY_PRESET_11
3 - FXAA_QUALITY_PRESET_12
4 - FXAA_QUALITY_PRESET_13
5 - FXAA_QUALITY_PRESET_14
6 - FXAA_QUALITY_PRESET_15
7 - FXAA_QUALITY_PRESET_20
8 - FXAA_QUALITY_PRESET_21
9 - FXAA_QUALITY_PRESET_22
10 - FXAA_QUALITY_PRESET_23
11 - FXAA_QUALITY_PRESET_24
12 - FXAA_QUALITY_PRESET_25
13 - FXAA_QUALITY_PRESET_26
14 - FXAA_QUALITY_PRESET_27
15 - FXAA_QUALITY_PRESET_28
16 - FXAA_QUALITY_PRESET_29
17 - FXAA_QUALITY_PRESET_39

Complexity of quality settings are based on default FXAA settings (revision 3.11)
10 to 15 - default medium dither (10=fastest, 15=highest quality)
20 to 29 - less dither, more expensive (20=fastest, 29=highest quality)
39 - no dither, very expensive
NOTE: FXAA can be enabled even if Post-Processing was disabled in advanced video options!
Ultima modifica di Crotalus il lun gen 02, 2012 4:19 pm, modificato 1 volta in totale.
Immagine
Crotalus
Corporal
Corporal
Messaggi: 798
Iscritto il: mar mar 01, 2011 10:24 pm
Località: Granze (PD)

Ho provato il massimo, 17, e sciambola! :o Sarà il quantitativo di memoria della scheda, i miglioramenti che i BI hanno apportato al gioco, ma sembra di vedere un aquerello da cartolina. Certo forse BF3 è migliore ma anche questo quà non scherza, poi le AI quà son migliori. :P ;D
Immagine
Giallustio
Colonel
Colonel
Messaggi: 2253
Iscritto il: dom feb 27, 2011 1:43 pm
Località: Genova

In BF3 non si parla di AI :P
[align=center]Volere è potere[/align]
Papo
Corporal
Corporal
Messaggi: 961
Iscritto il: mar apr 05, 2011 11:41 pm
Località: Trieste

Ma questo file .cfg da modificare dov'è? Nella directory principale non lo trovo.
Il settaggio dell' FXAA bypassa quello del pannello delle opzioni video o bisogna lavorare su entrambi?
Che casino! I miei applausi a Crotalus che si vede che ci azzecca :)
“A man afoot is half a man.” - A Texas Civil War cavalryman
Crotalus
Corporal
Corporal
Messaggi: 798
Iscritto il: mar mar 01, 2011 10:24 pm
Località: Granze (PD)

Il settaggio dell'FXAA lo puoi modificare solo dal file di configurazione di ArmaOA. Il percorso in cui trovi il file è C:\Utenti\Nome del tuo profilo\Documenti\Arma2\Arma2OA, trovi i valori nelle ultime righe. Se usi l'opzione non attivare il POSTPROCESSING, e neanche l'antialiasing perchè sarebbe solo un doppione di ciò che ottieni con Fxaa. ;)
Immagine
Rispondi