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.
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.
In 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.
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 the
same thermal restrictions ?
The 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.
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.
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.
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...
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.
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 ?
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 ?
Newer memory technology can be more power efficient than older ones so it may not be a big deal. Also you can't really fully shut down the DRAM due to refresh cycles that happen. But newer LPDDR technologies have different more efficient writing modes and can automatically clock down to save power.
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.
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 the
same thermal restrictions ?
Yep this is correct. But the major heat source is those 4xA76's. So its a huge extra cost on the RK3588 if we just turn them off. Could be interesting to see how much savings we could get by disabling other components we wouldn't need (at first at least) such as the NPU. Yet, while the RK3588 is 8nm, there is a loooot more inside. If we turn a bunch of this stuff off we can probably get it this to a manageable position, but I think a lot more would need to be done on the EE and ME side to make this viable (newer, more efficient peripherals, active cooling or improved passive cooling). I can't find the links where I originally got my TDP marks for these, but I remember seeing RK3568 vs RK3588 respectively at 6W and 7W for medium loads and 7W and 10W for heavy loads. Gadgetversus actually reports RK3588 as being a bit worse in terms of TDP https://gadgetversus.com/processor/rockchip-rk3568-vs-rockchip-rk3588/
So does Linux. Almost every SOC these days has some proprietary blobs being used that you will not be able to work around. Present in just about everything is the trusted firmware required for booting (not talking about bootROM, if you don't know what I'm talking about look up TF-A). In addition to this, there are sometimes blobs to handle various pieces which may be fairly transparent. For example, the iMX8 uses a proprietary blob in its DDR controller. And then of course the graphics libraries are always closed source (drivers are typically accessible source, but the userspace accelerators are 95% of the time closed).
It is exactly the same situation with Android as with Linux for this. The only difference is that sometimes manufacturers tend to make some other pieces of the source closed. The pieces which are typically only offered as binaries are:
- hwcomposer implementation
- vendor RIL (telephony implementation by modem vendor)
- some more I can't think of right now
And then pieces which are always closed source:
- OpenGL/Vulkan accelerators
- OMX/Codec2 components (media codecs)
I don't know for sure yet for the RK3568 or RK3588, but when I did some Android work on the RK3399, everything was available as source from RK except for the 2D/3D accelerators and the codecs. This was actually a pretty open system, just as open as it was for Linux.
I definitely get not wanting to use Android, and I'm not really recommending dropping Linux in favor of Android. Mostly pointing out that this is a split purpose device focused at two things: general computing and emulation/gaming. Unfortunately, the market has also split to favor general purpose on Linux and emulation/gaming on Android. This means that we will not be able to get great performance all in one hardware and software package. The user will need to make the choice regarding what their intended use is: general purpose or gaming. If general purpose, Linux or Android will work great. If gaming, the user is leaving a significant portion of the device's capability on the table if they do not select Android.
I understand suspend modes on x64 computers at least dumps out the RAM to swap so that it can power down the memory. I've never got that to work mind you.
I understand suspend modes on x64 computers at least dumps out the RAM to swap so that it can power down the memory. I've never got that to work mind you.
Newer memory technology can be more power efficient than older ones so it may not be a big deal. Also you can't really fully shut down the DRAM due to refresh cycles that happen. But newer LPDDR technologies have different more efficient writing modes and can automatically clock down to save power.
No, no. I was thinking more bluntly, you boot with less memory, part of it disabled and unpowered, for all the session, not powering up and down. So no refresh. Like you use all the RAM when you boot plugged and know you'll stay so, and choose part of it when you boot on battery or think you may unplug. I've never seen something like this, but it should be possible ?
OMAP5 product brief: https://www.ti.com/pdfs/wtbu/SWCT010.pdf The OMAP5430 offers a smaller 14x14 mm2 package with PoP LPDDR2 memory, while the OMAP5432 offers a 17x17 mm2 package with non-PoP DDR3 memory
Yep this is correct. But the major heat source is those 4xA76's. So its a huge extra cost on the RK3588 if we just turn them off. Could be interesting to see how much savings we could get by disabling other components we wouldn't need (at first at least) such as the NPU. Yet, while the RK3588 is 8nm, there is a loooot more inside. If we turn a bunch of this stuff off we can probably get it this to a manageable position, but I think a lot more would need to be done on the EE and ME side to make this viable (newer, more efficient peripherals, active cooling or improved passive cooling). I can't find the links where I originally got my TDP marks for these, but I remember seeing RK3568 vs RK3588 respectively at 6W and 7W for medium loads and 7W and 10W for heavy loads. Gadgetversus actually reports RK3588 as being a bit worse in terms of TDP https://gadgetversus.com/processor/rockchip-rk3568-vs-rockchip-rk3588/
Yes, that's understood. 7W is possibly too much. But I understand 7W is thermal dissipation power at max load ? Or is it some average or made up number?
My question is what performance can you get at say 4W TDP with RK3588. It should be more than what you get from a RK3568 at 4W TDP.
Now you're either running with half the SOC off or you're running with most of it on for a few ms and then sleeping it all a few more. Or throttling down clock most of the time, Or some such.
So you're paying 5 times more for a SOC and using only half or it or using it only half the time or something. But you should still get a little more processing than with the cheaper one.
Is it worth it ? Dunno.
I don't know for sure yet for the RK3568 or RK3588, but when I did some Android work on the RK3399, everything was available as source from RK except for the 2D/3D accelerators and the codecs. This was actually a pretty open system, just as open as it was for Linux.
Same here. That's what I meant with I don't know any showstoppers. Might be there, but not that I know. With RK3399 I think there was some blob needed for eDP but not HDMI ? Or whatever the PineBookPro used for the display.
I definitely get not wanting to use Android, and I'm not really recommending dropping Linux in favor of Android. Mostly pointing out that this is a split purpose device focused at two things: general computing and emulation/gaming. Unfortunately, the market has also split to favor general purpose on Linux and emulation/gaming on Android. This means that we will not be able to get great performance all in one hardware and software package. The user will need to make the choice regarding what their intended use is: general purpose or gaming. If general purpose, Linux or Android will work great. If gaming, the user is leaving a significant portion of the device's capability on the table if they do not select Android.
Well, as long as you can run linux-libre, a deblobbed TF-A and U-Boot withtout blobs it should be fine. Blobs for the modem and wifi I think we won't be able to escape.
Newer memory technology can be more power efficient than older ones so it may not be a big deal. Also you can't really fully shut down the DRAM due to refresh cycles that happen. But newer LPDDR technologies have different more efficient writing modes and can automatically clock down to save power.
No, no. I was thinking more bluntly, you boot with less memory, part of it disabled and unpowered, for all the session, not powering up and down. So no refresh. Like you use all the RAM when you boot plugged and know you'll stay so, and choose part of it when you boot on battery or think you may unplug. I've never seen something like this, but it should be possible ?
OMAP5 product brief: https://www.ti.com/pdfs/wtbu/SWCT010.pdf The OMAP5430 offers a smaller 14x14 mm2 package with PoP LPDDR2 memory, while the OMAP5432 offers a 17x17 mm2 package with non-PoP DDR3 memory
Yep this is correct. But the major heat source is those 4xA76's. So its a huge extra cost on the RK3588 if we just turn them off. Could be interesting to see how much savings we could get by disabling other components we wouldn't need (at first at least) such as the NPU. Yet, while the RK3588 is 8nm, there is a loooot more inside. If we turn a bunch of this stuff off we can probably get it this to a manageable position, but I think a lot more would need to be done on the EE and ME side to make this viable (newer, more efficient peripherals, active cooling or improved passive cooling). I can't find the links where I originally got my TDP marks for these, but I remember seeing RK3568 vs RK3588 respectively at 6W and 7W for medium loads and 7W and 10W for heavy loads. Gadgetversus actually reports RK3588 as being a bit worse in terms of TDP https://gadgetversus.com/processor/rockchip-rk3568-vs-rockchip-rk3588/
Yes, that's understood. 7W is possibly too much. But I understand 7W is thermal dissipation power at max load ? Or is it some average or made up number?
My question is what performance can you get at say 4W TDP with RK3588. It should be more than what you get from a RK3568 at 4W TDP.
Now you're either running with half the SOC off or you're running with most of it on for a few ms and then sleeping it all a few more. Or throttling down clock most of the time, Or some such.
So you're paying 5 times more for a SOC and using only half or it or using it only half the time or something. But you should still get a little more processing than with the cheaper one.
Is it worth it ? Dunno.
I don't know for sure yet for the RK3568 or RK3588, but when I did some Android work on the RK3399, everything was available as source from RK except for the 2D/3D accelerators and the codecs. This was actually a pretty open system, just as open as it was for Linux.
Same here. That's what I meant with I don't know any showstoppers. Might be there, but not that I know. With RK3399 I think there was some blob needed for eDP but not HDMI ? Or whatever the PineBookPro used for the display.
I definitely get not wanting to use Android, and I'm not really recommending dropping Linux in favor of Android. Mostly pointing out that this is a split purpose device focused at two things: general computing and emulation/gaming. Unfortunately, the market has also split to favor general purpose on Linux and emulation/gaming on Android. This means that we will not be able to get great performance all in one hardware and software package. The user will need to make the choice regarding what their intended use is: general purpose or gaming. If general purpose, Linux or Android will work great. If gaming, the user is leaving a significant portion of the device's capability on the table if they do not select Android.
Well, as long as you can run linux-libre, a deblobbed TF-A and U-Boot withtout blobs it should be fine. Blobs for the modem and wifi I think we won't be able to escape.
As I recall, the chip used for the Pyra doesn't support PoP memory, so I'm not sure if you're looking at the same chip there or just a prerelease set of documents there.
As I recall, the chip used for the Pyra doesn't support PoP memory, so I'm not sure if you're looking at the same chip there or just a prerelease set of documents there.
As I recall, the chip used for the Pyra doesn't support PoP memory, so I'm not sure if you're looking at the same chip there or just a prerelease set of documents there.
Yes, that's understood. 7W is possibly too much. But I understand 7W is thermal dissipation power at max load ? Or is it some average or made up number?
My question is what performance can you get at say 4W TDP with RK3588. It should be more than what you get from a RK3568 at 4W TDP.
Now you're either running with half the SOC off or you're running with most of it on for a few ms and then sleeping it all a few more. Or throttling down clock most of the time, Or some such.
So you're paying 5 times more for a SOC and using only half or it or using it only half the time or something. But you should still get a little more processing than with the cheaper one.
Is it worth it ? Dunno.
TDP is a generalized metric of average performance and efficiency. Looking at it very generally, a higher TDP indicates higher performance and lower efficiency (and of course a lower TDP indicates the opposite). However this is only a reasonable comparison between two very similar chips, as it doesn't take into account other things which could improve performance (acceleration, improved branch prediction, execution strategy, etc.). As a comparison between the RK3588 and the RK3568, this is fairly reasonable since under the hood they are very similar architecture and even share some core design. Note it does not indicate performance per watt.
Since we are heavily concerned with heat dissipation and battery life, we can use TDP to get an estimation of how much heat the chip will generate and how much power it will use. With the 5W TDP of the RK3568, we can presume it will be operating between 4-7W normally and around 0.5-2W in a low power mode (this is not pulled from TDP, I read this elsewhere). 5W TDP is about on target (close to the high end) for what we can handle in the Pyra for heat, ideally we'd be much lower because performance will decrease and battery could be damaged if we cannot keep the average temperature down. If we only consider the SOC and no peripherals, we can estimate that we will have a battery life between 3-5.5hrs when in use and 40hrs when in idle. This was calculated as below:
These are just estimates and do not take into account additional peripherals (i.e. modem, radio, display). Additionally, I do not have accurate information regarding the power consumption and power modes. I pulled a lot of this information from here, but this is not a battery device and so may not be configured efficiently. I can only assume these power metrics represent the PC as a whole rather than the SOC itself. For a more naive estimation, but likely more accurate, the Anbernic RG503 uses this chip and allegedly gets between 6-8hrs of game time on a 3500mAh battery. Pyra's 6000mAh battery is 1.7x the capacity, so we can expect 10-13hrs of game time assuming the rest of the system is equally efficient (and equally capable of dissipating heat).
Panfrost is good, but not optimized. Expect significantly lower performance than on vendor supplied libraries. Similar to how opensource NVIDIA drivers are functional, but significantly worse than the proprietary packages.
Well, as long as you can run linux-libre, a deblobbed TF-A and U-Boot withtout blobs it should be fine. Blobs for the modem and wifi I think we won't be able to escape.
This cannot all be guaranteed. Sometimes the blobs are deep in the SOC to where it cannot even communicate with DDR or eDP like you mentioned without them. TF-A is its own story.
It's not a metric, it's a design requirement selected by the manufacturer. It's a guesstimation rather than a value that is calculated from actually precise metrics and does not even represent the maximum power draw. A lower TDP can also be explained by the manufacturer thinking that a higher operational temperature is acceptable, therefore needing less cooling capacity. In this kind of power class we're not just talking about cooling solutions but also about ambient temperature, automotive chips often tend to operate in a rather warm environment.
The actual dissipated heat and power draw can deviate quite significantly from the provided TDP value, just look at the current generation of x86 CPUs.
Bit of number soup this thread is. For reference, the chip pencilled in by ED is the RK3568 while the super power one some people are speculating about running is the RK3588. I'd guess from the numbering that these RK3288 and 3399 are older chips though I don't really have any deeper understanding to bring to it.
I don’t have a lot of information in this regard, but I do have a little
A15:
Fetches 3 instructions per cycle
Dispatches up to 6 instructions for execution
Handles branch prediction, though the algorithm used is not shared (details are pretty limited but you may be able to find something)
A76:
Fetches 4 instructions per cycle
Dispatches up to 8 instructions for execution
Has an updated algorithm to properly accommodate the new width (there is some information on ARMs website which you can find after some googling)
A55:
Fetches 2 instructions per cycle
No dispatching, executes in order
New algorithm marketed marketed with name “neural network” (unsure what this means or where this is coming from, again details are not usually very public)
What about a Freescale/NXP i.MX processors?
They tend to have outstanding Linux support with good power management options. They have their ULP (Ultra Low Power) line that would probably be a good match for the Pyra. The core CPU is either Cortex-A53 or Cortex-A72, and the graphics chip is a Vivante GC7000 series GPU, which even has a open source driver: etna_viv
What about a Freescale/NXP i.MX processors?
They tend to have outstanding Linux support with good power management options. They have their ULP (Ultra Low Power) line that would probably be a good match for the Pyra. The core CPU is either Cortex-A53 or Cortex-A72, and the graphics chip is a Vivante GC7000 series GPU, which even has a open source driver: etna_viv
Mmmm. I.MX 8ULP seems not to have hdmi output (imx8M has it but only if you use a blob for HDMI). IMX8M needs blobs for DDR4. Does IMX8ulp need them too ? One year ago, cnx-software said i.MX 8ULP was 28 nm process.
I think it doesn't have SATA either, and maybe USB otg, but how many or is it USB2 or 3 ?
It has 2xA35 @1GHz and 1xM33@0.216GHz. Seems low computing power.
FCBGA 9.4 X 9.4 mm2; MAPBGA 15 x 15 mm2. It's smaller than OMAP5432 or the RKs we were speaking about.
I like i.MX6Q, but i.MX8M requires too many blobs. I don't know about i.MX8ULP or any other ULP.
There were a couple of articles in cnx-software.com about the Rockchip SOCs we were talking about, but I didn't take much anything of use for the Pyra.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
