Multi Discussão sobre PC e Consolas Nova Geração [Comparações -> Ofertas, Hardware, Performance etc.]

Nope. Tanto que por exemplo muitas apps de telemetria usam shared memory para aceder a memoria usada por outro programa. Ou como sistemas anti cheating funcionam por verificar o que esta em memoria. Ou como muitos trainers funcionam modificando a memoria que esta a ser usada por outra aplicacao. Sao 3 exemplos em que A acede a memoria usada por B.

A shared memory, que presumo que seja isto que te referes, é uma memória explicitamente alocada para as aplicações poderem trocarem dados, precisamente porque as aplicações têm o seu espaço de endereçamento privado, e se tentam aceder o endereço de uma outra aplicação sem ser essa memória partilhada, tens um crash garantido. Isto é o princípio básico de proteção de memória de todos os sistemas operativos modernos. É verdade que há formas de dar autorização para que uma aplicação possa monitorizar o espaço de endereçamento da outra (até para debugging). E sim, há truques que os trainers utilizam para subverter a proteção do windows no PC.

De qualquer forma, falávamos da Xbox e da decisão de ter o sistema operativo num core dedicado. Como deves saber, os jogos correm na UWP (Universal Windows Plataform) que isola ainda mais os processos uns dos outros, e torna esses acessos não autorizados mais difíceis ainda.

Realmente não percebes o que são threads, como são geradas, que recursos partilham entre elas e quando e que penalização existem.

Mas alguém pode dizer que percebe realmente de alguma coisa? :Winkani: Desculpa, tenho andado a jogar o Odyssey, e já foram muitas missões com o Sócrates. :)

As threads é um conceito simples - em C++ podes criar com pthreads ou OpenMP. Em Python, com o módulo threading. Igualmente simples é o modelo de memória: todas as threads de uma aplicação têm acesso ao mesmo espaço de memória. Mas existe a questão da cache L2.

Se tens 8 threads e elas estão a ler o mesmo bloco de memória, então há vantagens em pô-las a correr no mesmo núcleo. Porque a 1ª thread ao aceder esse bloco vai ter um miss e há uma penalização com um acesso a RAM, mas as outras 7 vão ter um hit. :beerchug:
Agora, se tiveres cada uma dessas threads num núcleo separado, vais ter 8 misses.:rcarton:

O sistema operativo não sabe a partida como é que as threads de uma app utilizam a memória e como agrupa-las de forma a maximizar a utilização da cache, por isso é que é necessário que um programador mais experiente dê essas indicações. Existe uma técnica de optimização da cache chamada "processor affinity" que pega nisso que acabei de explicar.

Isto para dizer que o que disseste aqui, não está correcto:

Partilhar um núcleo com threads de um programa ou de um serviço ou do mesmo jogo, vai dar ao mesmo. Um jogo gera centenas de threads, todas diferentes, com dependências diferentes. Que causa o mesmo problema que se fosse uma thread de um programa ou de um serviço.

Enquanto que as threads de uma aplicação podem de facto beneficiar da cache porque acedem o mesmo espaço de memória, não tens esse efeito quando a cache é partilhada com as threads das outras aplicações. O efeito de partilhar a cache com múltiplas aplicações é reduzir o tamanho da cache para cada uma delas, e isso pode ter um efeito negativo na performance.
 
Última edição:
Quando um jogo cria várias threads, estas não são todas iguais, nem usam os mesmos dados.
Sim, existe a vantagem de agrupar threads que usam os mesmos dados, o mesmo núcleo, ou pelo menos no mesmo CCX ou grupo de núcleos.
Se for possível fazer isto, temos um bom beneficio.
Mas no meio de tantas threads diferentes, é frequente que estes dados não possam ser partilhados. Por isso, ter uma thread do jogo ou uma thread terceira, que não usam os mesmos dados, é igual.
Para além disso, os ciclos de CPU que o OS gasta são tão poucos, que nunca vai compensar retirar o acesso de um núcleo e duas threads.
Nenhum OS gasta 12.5% de ciclos de um CPU, muito menos de um 8T16T.
Nunca vais ter cache misses a causar perdas de desempenho de 12.5%, por ter o OS a correr em qualquer núcleo.
A outra coisa a considerar, é que estamos a falar de um CPU OoO. Os dados são colocados em cache muito antes de serem precisos.
E quando já não são precisos, são retirados da cache, para dar espaço a novos dados.
Mais uma vez, o motivo para isolar um núcleo é para garantir que apps em segundo plano estejam a retirar recursos ao jogo em primeiro plano.
 
Mas já agora e só por curiosidade, acham que faria diferença ter mais um core disponível no Cpu das consolas?
Isto considerando o target delas, claro.
A ideia com que ficamos é que CPU existe e bastante...
Bottleneck a haver será sempre da parte do GPU, ou estou errado?
De todo o modo as primeiras indicações não são más, pelo menos considerando o dirt 5.
Temos 4k a 60fps, com gráficos que suponho sejam high|medium-high em PC.
Não está mau, até porque sabemos que estes jogos que sairão nos primeiros tempos, de Next Gen só têm o selo, portanto de futuro só melhorarão à medida que os Devs vão incorporando as novas tecnologias nos seus motores de jogo...
 
Seria melhor ter mais um CU no GPU, do que mais um core no CPU.

Isso na Series X representaria um incremento de 2% ao passar de 52 para 53 CU's.

Já os 12,5% no Cpu pode render mais se os Devs souberem que podem contar com essa potência extra.
 
Última edição:
Não sou grande fã de FPS (First-Party Shooters), acho que é um género que se adapta muito bem para o PC para quem usa o rato. É preciso maior precisão para controlar o campo de acção, e o controller parece-me pouco apropriado para fazer isso. Vamos ter pela frente vários AAA FPS nas consolas, o Cyberpunk e o Deathloop, por exemplo, e espero mudar a minha opinião sobre o assunto.
 
@xpure @Freddo @Ansatsu @brruno

Há uns tempos estávamos com umas questões sobre quais seriam os requisitos para o RTX IO, sendo este o lado do hardware da nVidia para a API Direct Storage da MS.

A resposta oficial da nVidia:

Will there be a certain ssd speed requirement for RTX I/O?

[Tony Tamasi] There is no SSD speed requirement for RTX IO, but obviously, faster SSD’s such as the latest generation of Gen4 NVMe SSD’s will produce better results, meaning faster load times, and the ability for games to stream more data into the world dynamically. Some games may have minimum requirements for SSD performance in the future, but those would be determined by the game developers. RTX IO will accelerate SSD performance regardless of how fast it is, by reducing the CPU load required for I/O, and by enabling GPU-based decompression, allowing game assets to be stored in a compressed format and offloading potentially dozens of CPU cores from doing that work. Compression ratios are typically 2:1, so that would effectively amplify the read performance of any SSD by 2x.

https://www.reddit.com/r/nvidia/comments/ilhao8/nvidia_rtx_30series_you_asked_we_answered/
 
Os nVme é garantido que funcionem todos. Isto porque tanto o GPU como CPU estão ligados por lanes PCIe. Não interessa a velocidade e a Gen.
Como diz o representante da nVidia, com SSDs a usar PCIe Gen4, teremos melhores resultados, mas não é obrigatório.

Em relação a SATA, não tenho a certeza.
Mas Sata Express usa o bus PCIe. Por isso, creio que SSDs ligados a um SATAe também funcionem.
Vamos ter de esperar para ver.
 
Em relação a SATA, não tenho a certeza.
Mas Sata Express usa o bus PCIe. Por isso, creio que SSDs ligados a um SATAe também funcionem.
Vamos ter de esperar para ver.

Seja como for, com SATA limitado a 500MB/s, o RTX IO não deve fazer qualquer diferença ao passar offload do Cpu para o Gpu.
 
@xpure @Freddo @Ansatsu @brruno

Há uns tempos estávamos com umas questões sobre quais seriam os requisitos para o RTX IO, sendo este o lado do hardware da nVidia para a API Direct Storage da MS.

A resposta oficial da nVidia:

https://www.reddit.com/r/nvidia/comments/ilhao8/nvidia_rtx_30series_you_asked_we_answered/
é a oficialização do que já fazia sentido...

De um SATA mesmo assim ainda deve haver algum ganho. Num caso hipotetico perfeito que a limitação passe a ser a velocidade da ligação , um SSD SATA seria 5x mais rápido que um HDD ( e actualmente ainda está bem longe disso por limitação da passasem de dados pelo CPU)
 
Segundo um leak recente, as RDNA2 no PC têm um desempenho em Ray-tracing acima do esperado. Com a 6800XT a igualar a 2080 Ti.
Do que se especula ainda destas gráficas, pode significar que tenha um rácio de TFLOPs para RT-TFLOPs de 1.5X

Quando o Andrew Goossen da MS, divulgou pela primeira vez a capacidade de RT da XBSX, dava um rácio de 1.1X
Isto colocava as capacidades de RT das consolas bastante baixa.

Mas se usarmos o rácio que vemos no leak das 6800XT, a coisa melhora um bocado.

A PS5 passa a ter o equivalente a 14-15 RT-TFLOPs, o que ainda fica abaixo de uma RTX 2060, mas não por muito.
E a XBSX fica com cerca de 18 RT-TFLOPs, o que a coloca entre a RTX 2060 e a 2060 Super.

As coisas estão a ficar mais interessantes :001:
 
Segundo um leak recente, as RDNA2 no PC têm um desempenho em Ray-tracing acima do esperado. Com a 6800XT a igualar a 2080 Ti.
Do que se especula ainda destas gráficas, pode significar que tenha um rácio de TFLOPs para RT-TFLOPs de 1.5X

Quando o Andrew Goossen da MS, divulgou pela primeira vez a capacidade de RT da XBSX, dava um rácio de 1.1X
Isto colocava as capacidades de RT das consolas bastante baixa.

Mas se usarmos o rácio que vemos no leak das 6800XT, a coisa melhora um bocado.

A PS5 passa a ter o equivalente a 14-15 RT-TFLOPs, o que ainda fica abaixo de uma RTX 2060, mas não por muito.
E a XBSX fica com cerca de 18 RT-TFLOPs, o que a coloca entre a RTX 2060 e a 2060 Super.

As coisas estão a ficar mais interessantes :001:
Mesmo assim ainda é fraquinho o uso do raytracing nas consolas. Já viste o devil may cry? Nas consolas para usares o raytracing a 60 fps tem que ser a 1080p. Não sei como isto vai ser no futuro.
 
Mesmo assim ainda é fraquinho o uso do raytracing nas consolas. Já viste o devil may cry? Nas consolas para usares o raytracing a 60 fps tem que ser a 1080p. Não sei como isto vai ser no futuro.

Até pode ser melhor do que isto. E mais uma vez, isto é especulação.
Mas se considerarmos que aquele teste de ray-tracing foi feito com uma RDNA2 com apenas 72 CUs.
Então o rácio passa a ser 1.67X. E se as consolas seguirem o mesmo rácio, em vez dos valores que o Andrew Goossen disse no inicio do ano, passa a ser:
A PS5 com o desempenho em ray-tracing de uma RTX 2060 em ray-tracing e a XBSX com o desempenho de uma 2070.
Com estes números, já nem parece tão mau...
 
Mesmo assim ainda é fraquinho o uso do raytracing nas consolas. Já viste o devil may cry? Nas consolas para usares o raytracing a 60 fps tem que ser a 1080p. Não sei como isto vai ser no futuro.

Tendo em conta que as próximas gráficas da Nvidia vao depender de DLSS para ter ray tracing a resoluções mais altas,não é assim tão mau.
Mas como dizes,o futuro não vai ser famoso para malta com as consolas de 2020 em termos de ray tracing. Quem quiser um salto vai ter de comprar os upgrades mid-gen que saírem,mas mesmo assim por essa altura já a NVIDIA meteu mais duas gerações de gráficas cá fora.
 
Até pode ser melhor do que isto. E mais uma vez, isto é especulação.
Mas se considerarmos que aquele teste de ray-tracing foi feito com uma RDNA2 com apenas 72 CUs.
Então o rácio passa a ser 1.67X. E se as consolas seguirem o mesmo rácio, em vez dos valores que o Andrew Goossen disse no inicio do ano, passa a ser:
A PS5 com o desempenho em ray-tracing de uma RTX 2060 em ray-tracing e a XBSX com o desempenho de uma 2070.
Com estes números, já nem parece tão mau...
Não parece mau, mas por exemplo, imagina uma 2060 a rodar o cyberpunk com raytracing e sem dlss, não acredito que de os 60fps a 1080p (com o dlss já deve dar bem).
 
Back
Topo