Announcement

Collapse
No announcement yet.

[ROM] Beelink GT1 / Alfawise S92 Stock & Nano Nexus ROMs (Android 7.1)

Collapse
This is a sticky topic.
X
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16

    In the long run 64 bits is the 32 bit replacement as happened with partition systems 10 years ago. I prefer cooler and softer than laggy and hot, however maintaining old technologies does not make changes for new things. It is even better for those who prefer Windows 7 than the 10. It is better to "stay with winning team" than to do substitution.

    Comment


    • #17
      Well me 2, i prefer 64bits... in the PC lol... but theirs some boxes now that takes advantage of the 64bits (rk3399's 4gb ram).
      Im only saying that is waste of time 64bits on this devices, they have poor hw, poor cooling solution, bad casings etc... and you really dont see any diference of the 2 you really dont!
      Now in the very very near future this will change a lot, is starting already as said above! (4gb ram)

      Comment


      • #18
        Originally posted by superceleron View Post
        Well me 2, i prefer 64bits... in the PC lol... but theirs some boxes now that takes advantage of the 64bits (rk3399's 4gb ram).
        Im only saying that is waste of time 64bits on this devices, they have poor hw, poor cooling solution, bad casings etc... and you really dont see any diference of the 2 you really dont!
        Now in the very very near future this will change a lot, is starting already as said above! (4gb ram)
        Well, when my boss tell me to convert our Android native app from 32bit to support 64bit armv8a, I too lazy (because it's need to change a lot 32bit integer variables to universal 64bit integer) and tell my boss like you said (we will go 64bit unless app need 4GB memory or more). But after some profilling, 64bit lib.so in 2GB devices really gain 15-40% performance in cpu update cycle (update functions work faster -> cpu can throttle down to lower clock faster -> cooling down faster).

        Btw about your claimed about overclocked S912 to true 8 cores 1512Mhz with 792Mhz GPU (I think you only changed some variables in dts file) in other S912 Android 6.0 rom. After tested your kernel and rom, I found that gain nothing. Geekbench 4 multicore still have same score (~2600 score), it should be 20% more if overclock really work. For GPU, kernel log showed that they can't read clock correctly when set to dvfs800_cfg as below attached picture (left is default kernel, right is "overclocked" kernel), and max clk / turbo clk doesn't change.

        I've same result when try to overclock Mediatek MT6753 / MT6755 SoC by change max clock speed of CPU and GPU, athough most system info app show new overclock frequency but dvfs table (control clock frequency) built in SoC doesn't make the chip switch to overclock frequency correctly.

        TL;DR DVFS table also stay in SoC and don't allow overclock frequency unless you found a way to disable it like engineer sample chip.

        Comment


        • #19
          Originally posted by longnt View Post

          Well, when my boss tell me to convert our Android native app from 32bit to support 64bit armv8a, I too lazy (because it's need to change a lot 32bit integer variables to universal 64bit integer) and tell my boss like you said (we will go 64bit unless app need 4GB memory or more). But after some profilling, 64bit lib.so in 2GB devices really gain 15-40% performance in cpu update cycle (update functions work faster -> cpu can throttle down to lower clock faster -> cooling down faster).

          Btw about your claimed about overclocked S912 to true 8 cores 1512Mhz with 792Mhz GPU (I think you only changed some variables in dts file) in other S912 Android 6.0 rom. After tested your kernel and rom, I found that gain nothing. Geekbench 4 multicore still have same score (~2600 score), it should be 20% more if overclock really work. For GPU, kernel log showed that they can't read clock correctly when set to dvfs800_cfg as below attached picture (left is default kernel, right is "overclocked" kernel), and max clk / turbo clk doesn't change.

          I've same result when try to overclock Mediatek MT6753 / MT6755 SoC by change max clock speed of CPU and GPU, athough most system info app show new overclock frequency but dvfs table (control clock frequency) built in SoC doesn't make the chip switch to overclock frequency correctly.

          TL;DR DVFS table also stay in SoC and don't allow overclock frequency unless you found a way to disable it like engineer sample chip.
          Hmm ok, not on this devices the 64bits system makes them a lot hotter than 32bits one, and dont take me wrong i do like 64bits... for me we should be already at 128 min...
          But on this devices HW i really dont see the point i really dont... but that is my opinion!
          Yes i know about the cpu clock, i never said it was OC not the cpu, but only the GPU... (i know that can only be done like you said in a engineer sample) the only thing i remove is the little/big endian limitation.. and is to make the system smoother and not faster, and i think that accomplices it.
          And i did stop the GPU OC because i dint see any gain on it only more problems and yes i did notice the error in the kernel log that was another thing that made me stop using it.
          Well i think we are now way offtopic here in Chad thread so lets stop it!

          Comment


          • #20
            Thanks for providing us all the support with new ROMs (which we should have been getting from Beelink ;-) ).
            Is read the dark screen bug was fixed in Andoid 7, but when I play the AVS HD 709 test files I still see that not everything below 17 is black and not all values higher than 235 are white.
            Or do I still need an RGB fix because I am using a Philips TV? My RPI (1) does not have this problem on my Philips TV.

            EDIT: Thanks Magendanz. Good to know that the RGB setting is a different problem. I do see that the output of the GT1 is now much more like what I get from my PC, RPI and cable box than under previous firmwares.
            After some reading up it could be that the RPi is 'cheating' by just clamping all pixel values between 16 and 235. I find the instructions for calibration rather confusing.

            So I assume the black screen bug has been fixed and I will tune my TV to the GT1 again. Thanks!
            Last edited by pederO; 08-15-2017, 00:10.

            Comment


            • Magendanz
              Magendanz commented
              Editing a comment
              I hear the RGB problem is much less subtle. Lots of bright colors. :-)

          • #21
            Still waiting for the wifi flashy thing

            Comment


            • Magendanz
              Magendanz commented
              Editing a comment
              Yeah, that's not going to happen until I return from holiday after the total eclipse.
          Working...
          X