Cheat Engine

[Slugsnack]

Just thought I'd throw this idea out there since I recently picked up CUDA (and some OpenCL). I was wondering on people's thoughts on creating a memory scanner using this technology. The problem of searching memory (especially small sizes) is extremely parallel and lends itself to GPGPU. I am sure significant performance gains can be made but not sure if I'm bothered. This project would be more for fun and learning although it is more than possible it could result in a faster CE.

The process I imagine is fairly simple:
- Copy pages to be scanned from main memory to GPU
- Each SIMD engine runs a warp/wavefront which fills a bitmap representing matches
- GPU result copied back to CPU

I think thread divergence can be avoided at stage 2 by using XOR operators and such.. Not sure on that one though.

Any thoughts or input ? Or has anyone attempted a similar project before ? Suggestions ?

[hcavolsdsadgadsg]

i'm not so sure this will lend itself to GPUs as well as you think.

[HomerSexual]

[hcavolsdsadgadsg]

it doesn't sound like a meaningful amount of work. if you could get everything scannable into memory in the right format but then all kinds of gotchas to avoid stalling, etc etc. it sounds like it could be branchy which is the last thing GPUs want to see. performance may be iffy without certain hardware support.

i don't know too much about it but it doesn't seem like a very applicable GPU problem. encoding videos and crunching math for folding proteins sounds sensible enough, this doesn't.

[atom0s]

I could have sworn I've seen something like this before. I'll keep an eye out for it if I can find it again but this sounds really familiar.

[Slugsnack]

[hcavolsdsadgadsg]

you're right that there's a lot of latency on the GPU, and that the throughput is high but you can stall it all the same. the pipeline is long but the throughput masks the latency. it's one of the reasons why you have to batch work so aggressively, the GPU can't feed itself.

i think you can explicitly keep synchronization but in case of a stall its possible for other threads to finish before others. data dependency / memory accesses may be problematic.

[Slugsnack]

i don't understand where you think there is a problem of data dependency in scanning memory which is all reading. you can not get conflicts (and hence stalls) from just reading and comparing.

of course you will get compulsory cache misses when the data is first copied to gpu memory before it reaches the caches but this is unavoidable either way. in regards to synchronization, i don't regard this as a problem. we have functions that block till the gpu completes such as cudathreadsynchronize()

maybe it is worth it to code a proof of concept comparison kernel since i think the main cause of the lengthy times of scans on ce is likely cache misses.

[Dark Byte]

the speed in scanning is dependent on the speed of ram, how much ram you have, and the harddisk speed
If you don't have much ram (e.g less than 4GB or you're on a 32-bit os) scanning a full game will be affected by the paging system because windows will be busy paging in and out memory of the game almost constantly

Most of the time when scanning on an old system the time spent waiting for the harddisk is greater than the time spent on comparing the memory

also, it's a bad idea to use ce 5.X and older versions from an USB stick as they store the temp results on the folder it's running from

[Slugsnack]

have you ever ran a profiler to determine what is the ratio of time spent computating compares and time to do memory loads ? if it is half, it may still be a worthwhile project