Olhando para CPU / GPU otimizações referência no Galaxy S 4

Será que a Samsung está trapaceando em testes de desempenho?  

De alguma forma, ambos Anand e acabei com versões internacionais do Samsung Galaxy S 4, equipados com a primeira geração Exynos 5 Octa (5410) SoC. Anand comprou um modelo internacional GT-i9500, enquanto eu estendi para o muito mais frio SK Telecom coreano modelo SHV-E300S, incluindo o próprio modem LTE da Samsung SS222 capaz de trabalhar em grupo 17 (AT & T LTE) e Banda 2,5 WCDMA em os EUA. Ambos vieram deNegri Eletrônica , um importador de dispositivo móvel em os EUA.

Para aqueles de vocês que não estão familiarizados com o Exynos 5 Octa nestes dispositivos, o SoC integra quatro núcleos ARM Cortex A15 (1.6GHz) e quatro núcleos ARM Cortex A7 (1.2GHz) em uma configuração big.LITTLE. Deveres GPU são tratados por um PowerVR SGX 544MP3, capaz de rodar em até 533MHz.

Ambos tinham planos de fazer um mergulho mais profundo sobre as características de um dos primeiros grandes plataformas de smartphone para uso do ARM Cortex A15 potência e desempenho. Como sempre, o ritmo insano de celular ficou no caminho e nós dois foi puxado em outras coisas.

Mais recentemente, um post sobre a Beyond3D  de @ AndreiF nos deu razão a poeira nossos SGS4s internacionais. Através de um bom old fashioned de benchmarking, o autor alegou que a Samsung só estava expondo o seu relógio GPU de 533MHz a certos benchmarks - todos os outros aplicativos / jogos foram limitados a 480MHz. Para as últimas semanas temos sido feita por muitos a olhar para isso, o que se segue são os nossos resultados.

Caracterizando Comportamento GPU

Samsung impressionante expõe o relógio GPU atual, sem a necessidade de acesso root. Basta executar o seguinte comando sobre adb e ele vai voltar a actual frequência GPU em MHz: 

adb shell cat / sys / module / pvrsrvkm / parâmetros / sgx_gpu_clk

Vamos torcer para que este não fique ligado, porque é realmente um nível extremamente útil de transparência que eu desejo fornecedores de plataformas móveis mais iria oferecer. Correr esse comandoem um loop podemos obter atualizações em tempo real sobre a freqüência da GPU, enquanto os aplicativos são executados diferentes cargas de trabalho.

A execução de quaisquer jogos, mesmo os títulos mais exigentes, voltou a frequência GPU de 480MHz - assim como @ AndreiF alegado. Samsung nunca reivindicou publicamente max freqüências GPU para o Exynos 5 Octa (nossa informação veio de fontes internas), assim nenhum dano não falta até agora.

Execução Epic Citadel - 480 MHz

Acender GLBenchmark 2.5.1 porém desencadeia uma GPU não está disponível em outros lugares: 532MHz. O mesmo é verdadeiro para AnTuTu e quadrante.

Execução AnTuTu - 532 MHz SGX Relógio

Curiosamente, GFXBench 2.7.0 (anteriormente GLBenchmark 2.7.0) não é afetada. Nós confirmamos com Kishonti, os criadores do índice de referência, que os testes de baixo nível são idênticos entre os dois pontos de referência. Os resultados do teste de transferência triângulo oferecer confirmação adicional para a diferença de frequência:

GT-i9500 Triângulo desempenho de throughput
Potência total do sistema	GPU Freq	Executar um	Executar 2	Executar 3	Run 4	Executar 5	Média
GFXBench 2.7.0 (GLBenchmark 2.7.0)	480MHz	37.9M Tris / s	37.9M Tris / s	37.7M Tris / s	37.7M Tris / s	38.3M Tris / s	37.9M Tris / s
GLBenchmark 2.5.1	532MHz	43.1M Tris / s	43.2M Tris / s	42.8M Tris / s	43.4M Tris / s	43.4M Tris / s	43.2M Tris / s
% De aumento	10,8%						13,9%

Devemos ver mais ou menos um aumento de 11% no desempenho em GLBenchmark 2.5.1 sobre GFXBench 2.7.0, e acabamos vendo um pouco mais do que isso. A razão para a diferença? GLBenchmark 2.5.1 parece ser apontada como um ponto de referência que é permitido executar o GPU no ajuste da freqüência / tensão superior.

A CPU também é afetada

O post original no B3D focado no desempenho da GPU, mas eu estava curioso para ver se o desempenho da CPU responderam de forma semelhante a esses benchmarks.

Usando o Monitor do Sistema mantive um olho na freqüência da CPU ao executar os mesmos testes.Acender GLBenchmark 2.5.1 provoca uma mudança para o ARM Cortex grupo A15, com uma freqüência padrão de 1.2GHz. A CPU relógios nunca cair abaixo disso, mesmo quando apenas ocioso na tela o menu do benchmark.

 

Esquerda: GLBenchmark 2.5.1 (1,2 GHz), Direita: GFXBench 2.7 (250 MHz - 500 MHz)

Executar GFXBench 2.7 e no entanto o SoC muda para os A7s Cortex rodando a 500 MHz (250 MHz de freqüência virtuais). Parece que só GLB2.5.1 tem permissão para executar neste modo de desempenho superior.

Uma verificação rápida em todo AnTuTu, Linpack, Pi Benchmark, e Quadrant revela o mesmo comportamento. O governador CPU é fixada em um determinado ponto, quando qualquer um desses benchmarks é lançado. 

Linpack para Android: Exynos 5 Octa todos os núcleos de 1,6 GHz (à esquerda), Snapdragon 600 todos os núcleos de 1,9 GHz (à direita)

Curiosamente, o mesmo comportamento (no lado do CPU) pode ser encontrado em versões de Qualcomm do Galaxy S 4 também. Nestes benchmarks selecionados, a CPU é definida como a freqüência máxima de CPU disponíveis no lançamento de aplicativos e fica lá durante o período, todos os núcleos estão conectados, bem como, independentemente da carga, assim que o aplicativo é iniciado.

Note-se que o comportamento da CPU é diferente do que vimos no lado GPU no entanto. Estas freqüências da CPU estão disponíveis para todas as aplicações de usar, eles são simplesmente forçados ao máximo (e, no caso de Snapdragon, todos os núcleos estão conectados), no caso de estes benchmarks. A freqüência máxima GPU 532MHz, por outro lado está disponível para esses parâmetros específicos apenas.

Indo mais fundo

Neste ponto, os benchmarks autorizados a funcionar em freqüências mais altas GPU parece arbitrário.AnTuTu, GLBenchmark 2.5.1 e Quadrant obter freqüências de CPU fixos e um máximo de 532MHz de clock da GPU, enquanto GFXBench 2.7 e Epic Citadel não. Bisbilhotando me deparei com a aplicação mudar o comportamento DVFS para permitir que essas mudanças de freqüência - TwDVFSApp.apk. Abrindo o arquivo em um editor hexadecimal e olhando para dentro cordas (ou apenas correr cordas no arquivo odex. ) apontou para o que parecia ser profiles / exceções para determinadas aplicações codificado. A string "BenchmarkBooster" é particularmente dizendo um:

Você pode ver o Android java convenções de nomenclatura específicas imediatamente na seção de destaque. Quadrant padrão, avançado e profissional, Linpack (livre, não pago), Pi Benchmark, e AnTuTu todos são chamados especificamente para fora. Nada para GLBenchmark 2.5.1, porém, apesar de seu comportamento similar. 

Nós também podemos ver os arquivos que são tocados por  TwDVFSApp enquanto ele está em execução: 

/ / Sys/class/devfreq/exynos5-busfreq-int/min_freq

/ / Sys/class/devfreq/exynos5-busfreq-mif/min_freq

+ / Sys/class/thermal/thermal_zone0/boost_mode

2/sys/devices/platform/pvrsrvkm.0/sgx_dvfs_min_lock

Quando o aplicativo TwDVFSApp concede status de DVFS especial para uma aplicação, o arquivo boost_mode vai do valor de 0 para 1, tornando mais fácil para verificar se um aplicativo afetado está sendo executado. Por exemplo, o lançamento e encerramento Pi referência:

shell @ android :/ sys/class/thermal/thermal_zone0 $ cat boost_mode                

1

shell @ android :/ sys/class/thermal/thermal_zone0 $ cat boost_mode                

0

Há cordas para Fusion3 (o Snapdragon 600 + MDM9x15 combo) e Adonis (o codinome para Exynos 5 Octa): 

doBoostAll

doBoostForAdonis

doBoostForAdonis ::

doBoostForFusion3

doBoostForFusion3 ::

O que é ainda mais interessante é o fato de que parece que  TwDVFSApp parece ter uma arquitetura de referência para outras aplicações que não sejam especificamente na whitelist para solicitar modo BenchmarkBoost como uma intenção, uma vez que o aplicativo também é um receptor de transmissão. 

6Lcom/sec/android/app/twdvfs/TwDVFSBroadcastReceiver $ 1;

6Lcom/sec/android/app/twdvfs/TwDVFSBroadcastReceiver $ 2;

? LCOM / seg / android / app / twdvfs / TwDVFSBroadcastReceiver $ IntentInfo;

4Lcom/sec/android/app / twdvfs / TwDVFSBroadcastReceiver ;

boostIntent

5com.sec.android.intent.action.DVFS_FG_PROCESS_CHANGED

* Com.sec.android.intent.action.SSRM_REQUEST

Portanto, não só pode ver o comportamento e empiricamente testar para ver quais aplicativos são afetados, mas também têm o que parece ser o whitelist e como o  TwDVFSApp  aplicação concede DVFS especiais para determinadas aplicações.

Por que isso é importante e que vem a seguir

Nada disto, finalmente, nos afeta. Nós não usamos AnTuTu, BenchmarkPi ou Quadrant, e afastou-se de GLBenchmark 2.5.1 tão logo 2.7 estava disponível (que caiu Linpack há um tempo atrás). O resto da nossa suíte não é afetado pelo governador CPU agressivo e otimizações de freqüência da GPU nas Exynos 5 Octa SGS4s base. O que isto significa, porém, é que você deve ser cuidadoso sobre a comparação Exynos 5 Octa baseado Galaxy S 4s usando qualquer um dos benchmarks afetados para outros dispositivos e tirar conclusões com base nisso. Este parece ser puramente uma otimização para produzir resultados reproduzíveis (e alta), em testes de CPU, e oferecer os mais altos possíveis benchmarks de desempenho da GPU. 

Dissemos há anos que a revolução móvel / irá espelhar a indústria do PC, e, portanto, não é nenhuma surpresa ver otimizações como este empregado. Só porque temos visto coisas como esta acontecem no passado, entretanto, não significa que eles devem acontecer agora.

É interessante que esta é uma espécie de reverso do que vimos fornecedores GPU fazer em FurMark. Para aqueles de vocês que não estão familiarizados, FurMark é uma ferramenta de teste de estresse que tenta fazer com que sua plataforma para tirar o máximo de energia possível. A fim de evitar a criação de uma situação em que as térmicas foram mais elevados do que seria durante um jogo normal (e evitar placas gráficas prejudiciais sem proteção térmica), vimos fornecedores GPU limitar a freqüência de clock de suas GPUs quando detectados estes poder- estilo vírus de apps. Em um dispositivo móvel que eu esperava ainda maior sensibilidade para algo como isto. Eu suspeito que vai finalmente chegar a esse ponto. Eu também gostaria de acrescentar que, assim como já vimos esse tipo de coisa muitas vezes no espaço PC, o mesmo é provavelmente verdade para celular. A dificuldade está em descobrir quando algo estranho está acontecendo.

O Samsung precisa fazer daqui para frente ou é abrir essas configurações para todos os usuários / aplicações (por exemplo, oferecem um ambiente configurável que corrige o governador CPU em um modo de alto desempenho, e destrava a freqüência 532MHz GPU) ou remover a otimização completamente. O risco de não fazer nada é que vamos acabar em uma corrida armamentista entre todos o SoC e fabricantes de dispositivos em que os montantes não insignificantes de tempo e esforço de engenharia é gasto em jogo os valores de referência, em vez de melhorar a experiência do usuário. Otimização para a experiência do usuário é tudo o que é necessário, boas referências beneficiar indiretamente - aqueles que não acabará por se tornar irrelevante.

Posted in: Tecnologia