IRC log of #cubox of Mon 05 Mar 2018. All times are in CET < Back to index

09:27 topi`> it seems the GC7000 Lite, which the 8m has, only has 16 shader cores. This translates to 64 GFLOPS, which is just 3 times the nominal perf of the Videocore-IV in Raspberrypi
09:28 topi`> but it's not bad either, it's a bit short of premium smartphone perf in 2012 (Adreno 320 in Snapdragon 600)
09:56 jnettlet[m]> yes that is correct. I will hopefully have some real world specs soon
10:03 Ke> when will you have the new cubox available?
10:03 Ke> what is the cpu freq btw.?
10:41 topi`> we have evaluated both the Compulab utilite2 (QS600 based) and the Hummingboard for a customer, and the 3D stuff on the QS600 is clearly way faster
10:42 topi`> I hope the 8M will do much better
10:42 topi`> (otherwise, I cannot recommend the Utilite2 to anyone)
10:42 topi`> mainline kernels fail to boot mystically
10:44 suihkulokki> I wonder which SoCs survive the Qcom-NXP-Broadcom merger for long term availability..
10:44 topi`> too many mergers going on...
10:44 topi`> they should complete the qcom-nxp merger first
10:45 topi`> from my point of view, all these APQxxxx attempts from Qualcomm to make decent embedded SoCs have failed to a certain extent.
10:45 topi`> from linux point of view, everything from NXP is much, much better documented
10:46 topi`> I'd venture to say it's impossible to get proper docs from Qualcomm. If Compulab was unable to get the required docs, then who can?
10:47 topi`> and Rob Clarke has to do reverse engineering on the Adreno
10:47 topi`> that's just pathetic
10:47 topi`> (OK, the same applies to Vivante, but anyway the GC parts are like black boxes and not everyone needs the 3D stuff)
10:48 topi`> I think the worst outcome from the merger would be worse availability of docs for the NXP parts
10:51 suihkulokki> topi`: re documents, you are correct
10:51 suihkulokki> topi`: but lots of the freedreno kernel code comes from codeaurora these days
10:55 suihkulokki> really the most effective way to force the hand of vendors
10:56 suihkulokki> 1. reverse engineer enough that mainline has somewhat working driver
10:57 suihkulokki> 2. wait for customers contact vendor "we have problems with mainline.." "don't use mainline, use our driver..."
10:58 suihkulokki> 3. "we tried your kernel but it is old and has problem and we miss all the nice features of newer mainline..."
10:59 suihkulokki> 4. "sigh, we'll assign someone look and fix issues in mainline, BUT WE WON'T SUPPORT IT"
11:03 Ke> Qualcomm categorically means not user controllable signed bootloader
11:03 Ke> good companies get eaten by the more predatory ones
11:05 topi`> or the ones who have the biggest army of lawyers
11:05 Ke> quite
11:06 topi`> I'm waiting to see the battle at the datacenter field when Qualcomm is going to attack Intel and both have huge armies of lawyers
11:06 topi`> Qualcomm might be a newcomer to the field with lots of disadvantages, but they also have a pretty decent war chest and experienced, veteran lawyers
11:10 suihkulokki> That is assuming the broadcom leveraged buyout doesn't choke the whole combined company under debt
11:33 topi`> yeah that sounds like a stupid buyout to me
11:34 topi`> why can't they just compete like everyone else :)
15:17 jnettlet[m]> topi`: but you were evaluating the etnaviv 3d acceleration right? It is still about 50% the performance of the binary driver. I expect the iMX8M to be about the same, most likely worse.
15:21 Ke> flops sounds like spec evaluation
16:23 jnettlet[m]> one of the big restrictions of the iMX6 series was the screw up they made on the memory controller. That has been fixed so the iMX8M should have a lot more memory bandwidth available for the GPU. This alone will help a lot
16:24 jnettlet[m]> fyi, the BSP is also now using the imx-drm driver for the iMX8M. the binary GPU driver can handle dmabuf file descriptors and the likes. Still digging in to how far the integration goes, and also the inner workings of the new VPU