darktable-chartEste capítulo toca em diversos tópicos técnicos que podem ajudar a fazer o darktable funcionar em hardware específico ou otimizar seu desempenho. Muita informação técnica adicional, informação de pré-requisito, dicas e truques também são cobertos por um extensivo blog que você pode encontrar na nossapágina.
 |
Os requisitos de memória do darktable são bem altos. Um cálculo simples deixa isto claro. Se você tem uma imagem de 20MPix, o darktable, para manter precisão, necessita armazená-la internamente usando uma célula de ponto flutuante de 4 x 32-bit para cada pixel. Cada imagem deste tamanho precisa de 300Mb de memória. Como queremos processar a imagem, precisaremos pelo menos de dois buffers para cada módulo - um de entrada e um de saída. Se tivermos um módulo mais complexo, seu algoritmo pode requerer buffers intermediários adicionais do mesmo tamanho. Sem nenhuma otimização, algo entre 600Mb e 3Gb seria necessário somente para armazenar e processar imagens. Além disso há o segmento de código do darktable, o código das bibliotecas carregadas dinamicamente, e os buffers onde o darktable armazena imagens intermediárias para acesso rápido durante trabalho interativo. De maneira geral, o darktable precisa de um mínimo de 4Gb para funcionar de maneira feliz.
Dado o que foi dito, é evidente que seu computador precisa de uma boa configuração de memória para rodar apropriadamente o darktable. Sugerimos que você tenha pelo menos 4Gb de RAM mais 4 a 8Gb adicionais de espaço de swap instalados. Este último é necessário para que seu sistema possa mandar para o swap dados temporariamente desnecessários para poder liberar memória RAM física.
Teoricamente, você também poderia rodar o darktable com menos memória RAM física e compensar isto com espaço em swap. No entanto, você deve estar preparado para que seu sistema eventualmente comece a fazer “thrashing” pesadamente, enquanto lê ou grava páginas de dados de e para o disco. Temos relatos positivos de que isto funciona para vários usuários, mas ainda pode ser extremamente lento para outros.
Além da memória total do sistema, há outro fator limitante: o espaço de endereçamento disponível na sua arquitetura de hardware. A quantidade de memória que pode ser endereçada por um processo depende do número de bits de endereçamento que sua CPU usa. Para uma CPU com registradores de endereço de 32 bits, serão 2^32 bytes, que dão um total de 4Gb. Este é o limite máximo absoluto de memória que pode ser usado por um processo e constitui uma situação bem justa para o darktable como vimos acima.
A rota de escape do darktable para isto é chamada de ladrilhamento. Ao invés de processar uma imagem em um grande pedaço, dividimos a imagem em partes menores para cada passo de processamento (módulos). Isto ainda requer um buffer completo de entrada e um de saída, mas os buffers intermediários podem ser pequenos o suficiente para que tudo caiba nos limites do hardware.
Infelizmente, isto ainda não é tudo. Existe um efeito chamado de fragmentação de memória, que pode e vai atingir software que precisa fazer gerenciamento extensivo de memória. Se um programa destes aloca 5 vezes 300Mb de cada vez e libera em seguida, esta memória deveria normalmente estar disponível para uma alocação de 1.5Gb em seguida. No entanto, é comum que este não seja o caso. O alocador de memória do sistema pode não ver mais esta área como uma região contígua de 1.5Gb de memória, mas uma sequência de áreas de 300Mb. Se não há outra área de 1.5Gb disponível, a alocação irá falhar. Durante a execução do programa este mecanismo tomará mais e mais dos blocos grandes de memória, em favor dos menores. O cache do darktable 2.0 aloca vários pequenos blocos de memória para cada miniatura, então este problema é ainda maior. Por este motivo, começando com o darktable 2.0, suporte a 32 bits está em processo de obsolescência.
Como se não fosse suficientemente desafiador, há outras coisas que podem limitar seu acesso à memória. Em algumas placas antigas você pode ter que ativar a opção da BIOS “memory remapping” para poder habilitar toda a memória física instalada. Além disso, se estiver em um sistema operacional de 32 bits você provavelmente precisará de um kernel que tenha “Physical Address Extension” (PAE) habilitada. Isto é comum em Linux, mas nem sempre. Muitas distribuições oferecem vários kernels diferentes, alguns com e outros sem PAR ativado; você precisa escolher o correto. Para verificar se seu sistema está configurado corretamente, use o comando “free” em um terminal e examine a saída. Se a saída reportar menos RAM do que você tem instalada, você tem um problema que precisa de correção; por exemplo, se tem 4Gb na placa, mas o kernel só vê 3Gb ou menos. Você precisa consultar o manual da sua BIOS e a informação da sua variante de linux para obter mais ajuda.
Como vimos, sistemas de 32 bits são ambientes difíceis para o darktable. Ainda assim, há alguns usuários rodando o darktable neles, respeitando os requerimentos básicos em termos de memória total do sistema e tratando apropriadamente dos tópicos mencionados nos parágrafos acima.
Há vários parâmetros de ajuste para fazê-lo funcionar. Em uma nova instalação, o darktable detectará seu sistema e determinará valores conservadores por default. No entanto, se você dizer upgrade do darktable de uma versão antiga, há boas chances de você ter configurações desfavoráveis em suas preferências. As consequências podem ser o darktable abortando devido a falhas de alocação - muito tipicamente - ou o darktable não conseguindo importar um rolo de filme. Como um sintoma frequente, você terá caveiras mostradas ao invés de miniaturas para muitas de suas imagens.
Se este for o caso, dedique alguns minutos à otimização das preferências. Você as encontra em “cpu / gpu / memory” (Seção 8.8, “Cpu / gpu / memória”) no diálogo de preferências do darktable. Você também pode encontrar estas preferências como variáveis de configuração em $HOME/.config/darktable/darktablerc e editá-las ali.
Aqui está uma explicação dos parâmetros relevantes e suas definições propostas:
Este parâmetro define o número de threads que são permitidas em paralelo ao importar rolos de filme ou fazer outras tarefas em background. Em sistemas de 32 bits você pode ter somente uma thread consumindo recursos de cada vez. Assim, você precisa definir este parâmetro em 1; qualquer coisa acima disso o matará.
Este parâmetro diz ao darktable quanta memória (em MB) ele deve presumir que está disponível para armazenar buffers de imagens durante as operações dos módulos. Se uma imagem não pode ser processada dentro desses limites de uma vez só, o ladrilhamento será usado, e a imagem será processada em várias partes, uma depois da outra. Use o menor valor possível de 500 como ponto de partida. Você pode experimentar depois, para verificar se consegue aumentar um pouco o valor para reduzir a sobrecarga do ladrilhamento.
Este é um segundo parâmetro que controla o ladrilhamento. Ele define um limite inferior para o tamanho de buffers intermediários de imagem, em megabytes. O parâmetro é necessário para evitar ladrilhamento excessivo em alguns casos (para alguns módulos). Defina em um valor baixo perto de 8. Você pode, tentativamente, aumentar para 16 depois.
Controla quantas miniaturas (ou mip maps) podem ser armazenadas na memória de cada vez. Inicialmente, defina em algo como 256MB. Desde o darktable 2.0, o cache aloca alguns pequenos buffers por miniatura, causando fragmentação de memória significativa. Como explicado antes, isto é um problema para sistemas de 32 bits. Por esse motivo, desde o darktable 2.0 suporte a sistemas de 32 bits está em obsolescência.
Não há muito o que dizer aqui. Claro que mesmo sistemas de 64 bits precisam de memória principal suficiente, então a recomendação de 4Gb mais o swap ainda vale. Por outro lado, arquiteturas de 64 bits não sofrem das limitações específicas de 32 bits, como espaço de endereçamento pequeno e a insanidade da fragmentação.
A maioria das CPUs modernas Intel ou AMD oferecerá espaço de endereçamento na faixa de vários Terabytes. A palavra “moderna” é relativa neste contexto: todas as CPUs introduzidas pela AMD e pela Intel desde 2003 e 2004, respectivamente, oferecem modo de 64 bits. Linux para 64 bits tem estado disponível por muitos anos.
Todas as distribuições relevantes de Linux dão a opção de instalar uma versão de 32 ou 64 bits. Você pode até mesmo usar binários de 32 bits em uma instalação de Linux de 64 bits. A única coisa que você precisa fazer: investir algum tempo na migração. No final das contas, recomendamos fortemente mudar para uma versão 64 bits de Linux. Realmente não há motivo para não mudar para 64 bits.
Em sistemas de 64 bits você pode deixar a configuração de parâmetros relacionados ao ladrilhamento em seus defaults: “limite de memória (em MB) para processamento de ladrilhos” deve ter um valor de 1500 e “minimum amount of memory (in MB) for a single buffer in tiling” deve ser 16. Caso esteja migrando de um sistema de 32 bits para um de 64 bits, você precisa verificar estas configurações e mudá-las manualmente se necessário no diálogo de preferências do darktable.
Tipicamente, não há necessidade de restringir o número de threads em um sistema de 64 bits. Em um sistema multiprocessador, um número entre duas e outro threads pode acelerar a geração de miniaturas consideravelmente, comparando com uma única thread. A razão não é tanto para tomar vantagem de todos os núcleos da CPU - a pixelpipe do darktable de qualquer maneira já usa todos eles em paralelo - mas esconder latência de entrada e saída.
Uma exceção vale ser mencionada. Se você usa o darktable para processar imagens panorâmicas feitas a partir de várias imagens individuais, por exemplo TIFFS gerados por Hugin, estas imagens podem atingir tamanhos consideráveis. Cada thread em background precisa alocar memória suficiente para manter uma imagem inteira mais os buffers de entrada e saída. Isto pode rapidamente levar mesmo um sistema bem equipado de 64 bits à exaustão de memória. Neste caso, diminua o número de threads para somente uma.
