removal of lazy memory allocation

[gregory]

Various reconpiler buffers are lazy allocated. We allocate the virtual memory but the physical memory is only allocated before a write.It was useful to limit ram requirement. However 90% of PC (steam stat) have at least 3GB of RAM. So the limitation is the virtual address space. Lazy allocation is quite useless.

I propose to remove lazy alloc on PC that have more than 4GB of ram (80% of market). It would increase the debug friendliness of PCSX2.(you know the countless exception at start up).

Then auperVU still consumes precious virtual address space for nothing (if mvu ofc). I don't have the number at hand but it could help a bit GSdx. Maybe we can find a way to avoid the alloc in mVU mode

[refraction]

Well mvu dynamically grows as you say, we can probably specify a comfortable amount which would be enough on most games as a base, that should reduce the effect considerably.

Remember however, without the large address aware, or limit is 2gb

[willkuer]

How do you avoid fragmentation and allocation bottleneck? Are they neglectable?
Sounds to me like there might be some cpu time reduction if you do allocation on start-up and not on-demand.

[Atros]

pls dpnt i m from those 10 % of ppl still having only 2 GB ram
Jk

[gregory]

pls dpnt i m from those 10 % of ppl still having only 2 GB ram
Jk

Come on, you play on a smartphone don't you. It would only be enabled on machines that have at least 4GB. And also after the future 1.4 release.

Well mvu dynamically grows as you say, we can probably specify a comfortable amount which would be enough on most games as a base, that should reduce the effect considerably.

Remember however, without the large address aware, or limit is 2gb

How is the growth achieve?

If you want to increase the buffer linearly, you need to reserve the address space first. So it already consume the scarce resources.

Mapping host memory for virtual systems...
    EE Main Memory                   @ 0x40000000 -> 0x42884000 [40mb]
    IOP Main Memory (2mb)            @ 0x44000000 -> 0x44211000 [2mb]
    VU0/1 on-chip memory             @ 0x48000000 -> 0x4800A000 [40kb]
Reserving memory for recompilers...
    SuperVU0 Recompiler Cache        @ 0x0E800000 -> 0x0F000000 [8mb]
    SuperVU1 Recompiler Cache        @ 0x0F000000 -> 0x0F800000 [8mb]
    Micro VU0 Recompiler Cache       @ 0x5C000000 -> 0x60000000 [64mb]
    Micro VU1 Recompiler Cache       @ 0x60000000 -> 0x64000000 [64mb]
    R5900-32 Recompiler Cache        @ 0x50000000 -> 0x54000000 [64mb]
    R3000A Recompiler Cache          @ 0x54000000 -> 0x56000000 [32mb]
    VIF0 Unpack Recompiler Cache     @ 0x56000000 -> 0x56800000 [8mb]
    VIF1 Unpack Recompiler Cache     @ 0x58000000 -> 0x58800000 [8mb]

OoO, sVU is quite small so let's forget about my previous idea (it was bigger value in my memory).

Will mVU need more than 64MB ?


Edit: actually sVU uses bigger memory when it is enabled.

[K.F]

pls dpnt i m from those 10 % of ppl still having only 2 GB ram
Jk

Come on, you play on a smartphone don't you. It would only be enabled on machines that have at least 4GB. And also after the future 1.4 release.

Jk = Just Kidding

[gregory]

Oh. Only serious discussion here

That being said, it would be so much cleaner to drop the SpatialArrayReserve monstruosity (vs a basic array).

I think it is only used for 2 buffers:
R5900 RAM copy @ 0xE2BFF000 -> 0xE4BFF000 [32mb]
R5900 RAM LUT @ 0xE07BF000 -> 0xE2BFF000 [36mb]

RAM requirements will only increase by ~50MB-60MB. But it won't increase the maximum of memory used by PCSX2.

[refraction]

How is the growth achieve?

If you want to increase the buffer linearly, you need to reserve the address space first. So it already consume the scarce resources.

I couldn't tell you without looking.

OoO, sVU is quite small so let's forget about my previous idea (it was bigger value in my memory).

Will mVU need more than 64MB ?


Edit: actually sVU uses bigger memory when it is enabled.

It's rare mVU needs more, mainly just games which constantly recompile due to it changing an I value in an opcode then running again (scarface does this) and it has to recompile the entire program.

SuperVU could quite possibly need more.

[gregory]

Yeah. Actually sVU uses normally 256MB. But value is reduced to 8MB when MVU is enabled. (it is kinds of my idea above).

Note: we can still keep lazy allocation on some mems. Initial goal is to reduce 80% of the exception. (some will remain due to memory protection anyway).

As a side note, I'm curious of the the usage of huge TLB page (page of 2MB instead of 4KB).

[refraction]

No idea? Maybe somebody had an optimization planned? I couldn't tell you, I've never worked on memory allocation and lookup tables