Re: [DISCUSSION] Hexagon code inside kernel

[cotulla@yandex.ua]

Hi,

> šFor the qdsp6v3 the effective clock rate was 300MHz per core, so yes.
> šIt might be even slower for v2, not sure. š(the chip clock rate is 1.8
> šGHz, there are 6 interleaved cores, so 1.8/6 = 300 šThe power savings
> šare not from the clock rate, but from the tiny transistor count. The
> šperformance efficiency is from keeping all of those transistors
> šconstantly wiggling, which is what the interleaved pipeline does.)

Hm, I thought the maximum clock rate is 595.2 Mhz?
Or 1.8 is another clock?
But by changing this clock rate I can get different Q6 performance.

> šNoo .. in fact, that slow clock rate meant it's more or less the same
> šspeed as DRAM. šSo low penalty for cache miss. šBut there's also a bus
> šbetween here and there, and I think it was selected for simplicity not
> šspeed...
I thought that it can be bus arbiter setting, but other masters like MODEM and APPS were almost idle during test.
I think in that case Q6 can take whole bandwidth or is it still limited somehow?


> šOh, well, no, the VM wasn't created for linux, it was created for all
> šthe other junk they try to run on there (eg audio processing, noise
> šcancellation, etc.), so that there would be a forward migration path
> šfor that software with each new chip generation. šWhether those other
> šsoftware parts actually used the thing, and in what time-frame or
> šrelease .. hey .. typical big-company inter-divisional politics,
> šbickering, etc. šThe truly daring wanted all those other parts to run
> šon the linux kernel. šThe old-school was like "hell no we don't need
> šno stinkin OS, we'll hand code everything in assembly" which sounds
> šgreat until you have ten support staff helping them kludge up a really
> šreally badly designed home-grown linker/loader/scheduler/irq-handler.
> šSometimes, really smart people just don't get it.

Well, sometimes such code becomes too large and slow, while doesn't provide universal solution for all cases.
As well as more code == more bugs inside and harder to follow logic inside. 

> šDon't know v2. But v3 had a 'real' MMU
Hm, are you sure in that? 
I had never seen any usage of it. As well as binutils registers definition doesn't include any suitable registers for that. 

> šGood, because the bootloader was going to be the other issue.
Yes, in my case it's working :)
But another guys who also want participate in this project with MSM8960/APQ8064 they still can't run any unsigned code on Q6.
In modern phones it's often locked from changes :(

> šI'd done the patches for glibc (yes, they're publicly available on
> šsome website, don't know if they got merged or not), got 98% of the
> šmany hundreds of glibc unit tests to pass, including most or all of
> šthe thread tests including TLS. Someone had bootstrapped hundreds of
> š.debs and both python and perl passed 100% of their tests. šI'm sure
> šno one cares, but even guile worked, and I was about to start fiddling
> šwith haskell :-)
Good to hear that. Good job!
So userspace support is rather good in common.
Maybe we will try to compile and run Android on that 6 cores pff hardware threads :D


-Cotulla