hd4870 contro gtx 260

[okorop]

Originariamente inviato da Ale985

io quando gioco la metto al 45%, il rumore non è eccessivamente alto.
Comincia a rompere sopra il 50% secondo me

quoto comunque himo adesso come adesso è meglio la gtx260 amp al quadrato...va come una gtx280

[Ale985]

Originariamente inviato da yossarian

La capacità di un chip di gestire gli accessi alla ram si vede, a parità di ram, da come sfrutta la banda passante (se ha meno banda passante e va meglio o uguale ad un altro con maggior bandwidth e potenza di calcolo comparabile, allora riesce a gestire gli accessi alla vram in maniera più efficiente).
Per ovviare in parte a questo inconveniente, RV770 può usare una scorciatoia, sempre che la stessa sia supportata, che è quella di accedere direttamente alla ram di sistema senza dover caricare i dati nella vram: questo risparmia un passaggio (la trafila sarebbe: ram->vram->registri->alu e si salterebbe il passaggio attraverso la vram).

Quindi significa che il processore grafico va a pescare direttamente dalla memoria centrale le istruzioni dei frame precedentemente calcolate dal processore.
Ma nella memoria video allora venogno caricate le istruzioni per i filtri, bump mappings....?

Poi volevo chiederti un'altra cosa: cos'è il deferred rendering?

[yossarian]

Originariamente inviato da Ale985

Quindi significa che il processore grafico va a pescare direttamente dalla memoria centrale le istruzioni dei frame precedentemente calcolate dal processore.
Ma nella memoria video allora venogno caricate le istruzioni per i filtri, bump mappings....?

no, è una funzionalità che si attiva solo all'occorrenza, una volta esaurita la vram e non un'alternativa alle procedure di rendering tradizionali, anche perchè le latenze per l'accesso alla ram di sistema sono più elevate (anche se sensibilmente meno elevate del caso in cui la vram debba swappare verso quella di sistema e, in un secondo tempo, la gpu caricare i nuovi dati dalla vram).

Originariamente inviato da Ale985

Poi volevo chiederti un'altra cosa: cos'è il deferred rendering?

nel rendering tradizionale, per ogni frame si calcola la profondità di ogni oggetto e si riempie un buffer (lo z-buffer) all'interno della vram; i dati ivi contenuti sono utilizzati per applicare il MSAA per cui si fa uso d 8 bit Interi per canale; quindi il MSAA box filter si applica solo sui bordi dei poligoni che comprendono il frame e non su tutta l'immagine. Una volta che gli shader hanno calcolato i valori di luminanza e crominanza (praticamente quelli relativi ai 3 colori fondamentali e il canale alpha per ogni pixel), si passano i risultati alle rop's che "scrivono" i valori calcolati dallo shader core; solitamente le rop's possono utilizzare diverse modalità di blending, dai classici 32 bit Interi (8 per canale, oppure 10 per i 3 colori e 2 per il canale alpha) ai 16 bit per ogni canale, interi o in floating point, fino ai 32 bit in floating point (fp32) per canale (quello che tecnicamente viene definito full HDR anche se pure la modalità fp16 viene considerata, di fatto HDR). A questo punto, si procede alla rimozione dei poligoni nascosti (HSR) (in realtà una prima grossolana eliminazione delle superfici nascoste si fa quando si crea l'immagine in wireframe). Un motore che fa deferred rendering inverte l'ordine di queste due fasi, ovvero, prima si rimuovono le superfici nascoste e poi si procede al rendering. Per fare ciò, però, si deve fare in modo di poter conservare i dati contenuti nello z-buffer che, all'occorrenza devono poter essere riutilizzati. Ad esempio, in motori che applicano algoritmi di illuminazione dinamica, qualora non fosse possibile conservare questi dati, perchè cancellati con le operazioni di rimozione delle superfici nascoste o di blending nel momenot in cui si applica il MSAA. Altrimenti, in giochi tipo stalker, oquelli basati sull'UE3 che fanno uso di illuminazione dinamica, ogni volta che cambia l'illuminazione della scena bisogna calcolare di nuovo tutta le geometria (ovvero i dati dello z-buffer).