17mm ? Where did you find the size ? I searched for some time but couldn't find it and finally I had to guess it from soem EVM picture and board size. But it had a heat sink on, so it might be smaller indeed.At that price point, I think the RK3568 is looking really good. When considering the dimensions as well, I think the RK3588 is just too big. Not exactly sure which package you went with for the OMAP5, but looks like it'd be 17mm, which means the RK3568 is worth trying, RK3588 is probably much too big.
I think RK3588 is made with 8nm lithography and RK3568 at 22nm ? That may change power dissipation. I doubt you can use RK3588 at full performance in a Pyra, but maybe the capped performance would still be higher than a what a RK3568 would give you with theIn terms of some realities of heat dissipation with regards to RK3588 and RK3568, the RK3568 will definitely be easier to keep cool. However, it is easier to keep cool because it has no high performance cores, so we take a hit there (the A15's in the OMAP5 are previous generation high performance cores). The RK3568 has proven to perform quite well for the general purpose tasks, but its going to be making more use of all those cores in order to do it, since each one is less performant and, importantly, does not support out-of-order execution. I would expect slightly better general purpose performance than the OMAP5 and roughly the same or maybe even a little bit worse for emulation. No reasonable PS2 emulation on this SOC, but up to it should be ok.
same thermal restrictions ?
No idea, but sounds sensible. But again, 8nm vs 22nm should give some wiggle room, after all both RK3568 and RK3388 are ARMv8.2-AThe RK3588 will perform significantly better, up to Gamecube (it can even do some Wii and Switch emulation). However, heat will be a serious challenge with this. In reality, in order to deal with this we would probably have to leave off most of the A76 cores and probably just run with 1, maaaaybe 2. At full blast (so when doing GC, Wii, Switch) this chip actually will need more like 10W with all cores on. I also have some concerns regarding the current power supply capabilities of the existing circuit, especially surrounding the battery charger in early boot phases. We're barely able to get the OMAP5 going due to limitations in early boot with the input current limit on the BQ charger chip. We need the SOC to be running in a limited power state early on in order to open up the gates and allow more current in, which the RK3588 may need too much to get kicked off for this. ARMv8's secure boot sequence introduces some limitations here which could require us to make changes to the main board to get this to work. The RK3568 also poses risk for this, but the risk is less.
RK3568 seems to have some linux support already, and RK3588 may have it in the future, but we can't know for sure. I'm not interested in Android support, because Android requires proprietary stuff and remote services and support is typically shortlived anyway.Then of course there is the issue of OS. These days, mobile cores for higher performance graphics are really targeted at Android. In particular, these chips we're discussing are targeted at EdgeAI purposes on Linux. As such, the acceleration libraries provided by RK (this is almost always closed-source) reflect this. Android has kind of taken over as the target platform for emulation, and so the emulators themselves are better optimized for this platform. Similarly, manufacturers of chips such as these focus their efforts on optimizing their graphics acceleration libraries for Android and spend less time on the Linux versions. One may argue that Android runs the Linux kernel, so it should be the same, but it is not. There are separate OpenGL/Vulkan userspace libraries for Linux and Android as Android has specific requirements and additional features which need to be supported. You can see this in particular with the RK3588, which can handle emulation very well under Android, but actually quite poorly under Linux (see the end of the video I posted earlier). This means that regardless of which chip we use, we really must begin considering Android as a platform when targeting emulation. Linux is clearly much better for general purpose behavior, but for emulation and web browsing (which both heavily depend on 2D and 3D acceleration) Android is likely to have significantly better performance.
I think short term support is not very relevant for a Pyra, and the community will have to maintain it itself. So I'm more worried about blobs and signed bootloaders (requiring vendor keys the user can't replace) and so on than current day binary support. I don't know any showstopper for RK3568 or RK3588 but that may be just my lack of knowledge.
So RK3568 is safer (like having Panfrost already done) and RK3588 is more uncertain, but also RK3588 is newer, so any support might last a little longer than RK3568...
Yes. RK3566 can use at most 4GB RAM, RK3568 8GB and RK3588 16 GB ? Do we care ? If we ever put more than 4GB in the cpu board we'd need some way to power down part of it to save power ?Also, it doesn't really seem to me that we would make good use of any of the features of the RK3568 over the RK3566, so maybe that is a better target as its cheaper.