Thanks wll1rah,
I was able to run cn/r, cn-pico and cn-heavy. The other algos, especially all the rx…, end with OOM killer (not enough RAM), even though CPU miner runs well.
The fastest settings are:
"intensity": 64,
"worksize": 16,
And I’m getting these hashrates:
cn/r 3.1H/s
cn-heavy 3.8H/s
cn-pico 43.9H/s
Though, it is not much compared to the hashrates of the CPU part:
cn/r 22.8H/s
cn-heavy 32.2H/s
cn-pico 1409.3H/sYour correct, But what I’ve been doing is mining UPX which has a really small scratchpad size of 128KB so it can fit in the CPU’s Cache memory freeing up the rest of the system to use the GPU, for something like the other CN algo’s. Also your not really out of memory the share size with the system ram is the problem and I’ve got no idea how to adjust that with the O.S./ kernel and then what the limits are I think being able to have a larger pool of memory would help get the hashrate higher but this is a really low powered GPU to begin with, so I’d not expect great results. It’s more of how it gets utilized and something like chukwa would be great but no miner that works with the Mali/ Intel GPU’s
Yes it is, this is my old discord handle and my github repo, but that’s most instructables
Ah - thought i recognised the handle! Neednt have banged on about my miner when youve seen it here already!
It’s okay, It’s good to brag. I could have said something before, but no need, others in the UPX discord might not have seen it.
I did test out the Odroid C4 on RandomX and got ~122H/s which 1/4 of a GTX 10606GB, Power draw is ~3W at wall, I wish Khadas would release a VIM3L with 4GB of RAM I think it would kill off the RK3399 boards not cost wise but price/performance wise for sure especially in W per Performance
4G VIM3L, interesting, but how does a 8G VIM3 sound ? 
,
but anyway a 8G is not possible as the memory address on the VIM3 is max of 32 bits,
Atleast expect it in the VIM4 (if something like that comes out) 
8g is wasted memory for crypto mining! Need 4g to fit the randomx algo in though!
Odroid C4 on RandomX and got ~122H/s
4GB VIM3 on CPU does 226H/s, even not using all cores. Actually using all cores hurts performance (and consumption). The best setting seems to be "rx": [0, 1, 2, 3], i.e. two big cores (2,3) and two little cores (0,1). The reason probably is two L2 caches (each 512kB), one exclusively for big and one for little cores.
Probably on Odroid C4 you’ll also get better performance using just 3 or 2 cores out of 4. The cache should be comparable (only 512kB). The best way to get cache properties is a little program cache-info from here.
well yes but what if you wanted to do something else, it might have been useful, just saying
Oh yes definitely I agree!
The new RPi has a less powerful SoC and 8GB of ram, the VIM3 has a more powerful SoC but only 4GB of ram, its like both these combos were made in Heaven 
RPi4 misses ARMv8 crypto-extensions, so there is no HW AES instruction and mining is a bit slower. I can get rx 104H/s on 3 cores.
yes that’s why i said ,
but I don’t understand why those extentions are not included, maybe it’s because it uses a custom SoC ?
The Cache structure is different between armv8.2-a and armv8-a, I’ll try what you suggest. but the cache for the VIM3L as well as the Odroid C4, is or should be L1, L2, and L3 the L2 is per core and independent while the L3 is system wide.
8GB of ram for SBC is wasted memory even the 4GB RPI is more than enough, If they had wanted to boost actual performance they would have either added more L2 cache or added AES and/or Crypto extensions, Same with the VIM3 it’s actually disappointing that it’s only got 512KB for the 4 A73 cores should have been a minimum of 1MB ideally 2MB and given the cost you can’t tell me there wasn’t room to add them.
Cache structure for the Odroid C4
$ ./cache-info
Max cache size (upper bound): 4194304 bytes
L1 instruction cache: 4 x 32 KB, 4-way set associative (128 sets), 64 byte lines, shared by 1 processors
L1 data cache: 4 x 32 KB, 4-way set associative (128 sets), 64 byte lines, shared by 1 processors
L2 data cache: 4 x 128 KB (exclusive), 4-way set associative (512 sets), 64 byte lines, shared by 1 processors
L3 data cache: 1 MB (exclusive), 16-way set associative (1024 sets), 64 byte lines, shared by 4 processors
It’s got and extra 512KB that the VIM3 Doesn’t
and they took the halfway point for the L2 cache
