On 03/28/2014 11:42 AM, Siarhei Siamashka wrote:
On Thu, 27 Mar 2014 16:26:02 +0100
Hans de Goede <hdego...@redhat.com> wrote:
Hi,
Thanks for the patches. I've merged and pushed the 1st one.
The 2nd one esp. is a good find and a nice cleanup.
It also seems to explain why we were getting various reports about
instability on the cubieboard2, which ships with a dram clock of 480
where as it seems to be stable at 432, which exactly matches the
threshold above which you say the timings become wrong.
As Olliver already indicated we would like to do some more tests with
the 2nd patch first, but eventually we definitely will want to merge
it (assuming the testing goes well).
I'm thinking that this means that we may be able to safely bump the dram
clock on the cubietruck to 480, any opinion on this ?
I have a Cubietruck, which can successfully boot to a login prompt
with dram clocked at 504MHz. And a Cubieboard2, which can also boot
to a login prompt with dram clocked at 552MHz respectively.
However it does not mean that these devices are going to really work
stable in these configurations. I have tried different tests and
workloads during the last year or so. And it appears that competing
memory accesses from both ARM CPU and Mali GPU tend to cause problems
at the memory clock speeds, which are otherwise stable for CPU-only
workloads.
I understand that setting up binary drivers and then running some 3D
accelerated applications while checking for memory corruption bugs at
the same time is not something that many people would enjoy (or even try
in the first place). And I had plans to try to simplify the test setup
since a long time ago. Finally here it is:
https://github.com/ssvb/lima-memtester
Basically, that's just a single static binary with no dependencies.
It combines a memtester tool with a simple spinning textured cube
demo from the work-in-progress free open source Mali400 driver
project http://limadriver.org/
That's amazing, we should prep a rootfs with all of that in it maybe
too? setting up lima + mali + god knows what may be a bit too much for
some right now, so having a pre-defined test rootfs might proove usefull...
It would be 100% free software using only free software tools if the
open source lima shader compiler could handle vertex shaders. Right now
only the fragment shader binary had been generated using the open
source shader compiler. But the vertex shader binary (injected as an
array into the source code) still used the output of the proprietary
shader compiler from the libMali.so blob.
Anyway, my Cubietruck passes the test at 456MHz dram clock speed and
fails at 480MHz. And my Cubieboard2 passes it at 504MHz but fails
at 528MHz. The second patch from Jens Kuske unfortunately does not
seem to have any visible effect here and does not change anything
for me.
That's unfortunate, I slightly hoped that the proper timings would
result in better performance.
But all hope is not yet lost, maybe on badly designed boards
(tablets/mele) it does work better with the right timings.
More test results using different hardware are welcome.
Olliver
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
