cosiderazioni sulle 9500 modificabili

[athanatos]

fino a qualche tempo fa mi chiedevo:

come mai hai tempi delle GeForce/Geforce 2 le modifiche Hardware erano così "facili" da fare e soprattutto mi pare che l'esito della modifica fosse praticamente certo e con queste "nuove" ATI, la cosa è più complicata e soprattutto tutt'altro che certa?

Si è parlato a lungo della modifica. E le ipotesi più in auge sembrano quelle che vogliono le 9500 non modificabili dotate di procesori di "seconda scelta", con Pipeline rovinate o non funzionanti alla perfezione.
Ammetto di non essermi mai convinto appieno di ciò.
E' vero che cose del genere si facevano dai tempi del 486 (Dx e Sx, venivano dalla stessa liena di produzione ed il modello Sx veniva modificato (non ricordo... veniva rovinato o non veniva saldato un collegamento interno...)), e chissà da quanti anni i produttori di resistenze con un controllo di qualità misurano le tolleranze e calssificano le resistenze come precise al 10% o al 5% o al 2%, in base al loro discostarsi del valore effettivo dal valore nominale di progetto stampato.
Però mi dicevo: non può essere. Deve esserci sotto qualcosa di altro. Non è possibile che mettano sul mercato prodotti che possano non andare (del resto pare proprio che i chip R300 venissero tutti dalla stessa linea di produzione); o meglio non credevo avessero potuto realizzare un progetto con ampie possibilità di scarto.
Ammettiamo che ci siano effettvamente delle parti che non vanno, ammettiamo che ci sia una pipeline difettosa. Dopo il test (e credo plausibile che le GPU siano tutte testate, anche solo per il controllo qualità), quelle che presentano problemi vengono declassate.
Quale delle pipeline non va? Non so come sia organizzato il DIE (ma non cambierebbe nulla, non so niente di elettronica e di fisica dello stato solido), ma immagino che potrebbero essere disposte 4 + 4 pipeline da qualche parte sul DIE. Come si fa a decidere fisicamente quale gruppo escludere? Se ne occupa il Bios? Fa un po' come per gli HardDisk e "segna" quella incriminata?
Ipotesi più maliziosa: non è che il progetto sia stato un po' al limite e 4 pipelinee siano state disposte in una zona "a rischio", magari ad un bordo o in un punto più soggetto a guasti/sollecitazioni durante il processo litografico? (noi testiamo... se va 9700/9500PRO... se non va 9500...)? Ipotesi troppo fantasiosa?

Ultimamente poi è arrivato Doom3. Il gioco non l'ho visto e non so come sia, ma più che un gioco (che magari è bello o brutto), sembra un programma di Bench. Pare che tanti overclockatori abbiano riconosciuto e scovato instabilità nei loro sistemi più con Doom3 che non con i vari Prime95 o SuperPI (o altro... no nconosco bene i programmi). Anche questo non vuole essere una critica al gioco. Se poi il gioco richiede tanta potenza non fa altro che fare quello che i vari Prime ecc fanno da tempo: stressare tutta l macchina, CPU, RAM, GPU... magari HD con swap.
Ho letto anche di gente che incomincia ad avere problemi con le 9700 (più o meno PRO e più o meno overclokate), accusando gli stessi problemi che sembrano affligere alcune 9500 non modificabili: i così detti artefatti, quei puntini che alcuni attribuiscono alla presenza delle ipotizzate pipeline rivinate.
Allora davvero l'R300 era un progetto ultra ottimizzato e tirato al limite (nessuna polemica in tutto ciò), che sotto stress adesso accusa qualche problema o qualche limite?

E se allora prendessi una 9500 modificabile a 9700, ma che ha problemi di artefatti e la underclocko? Riacquisterei stabilità e scomparirebbero i puntini?

In definitiva: è mai saltata fuori la verità su tutto ciò? Fino ad ora ho sempre sentito parlare di ipotesi (più o meno plausibili, ma pur sempre ipotesi).
Qualcuno ne sa qualcosa di più? Qualcuno può aiutarmi a chiarire un po' o magari è semplicemente interessato alla questione?

Spero di non essere stato troppo lungo e soprattutto di non essere andato un po' OT, visto che qui si parla di modifiche/tweak/overclock, forse con un tglio un po' più pratico (e meno male anche che sia così... un taglio più teorico sarei il primo forse a non poterlo seguire)

Grazie a chi avrà avuto la pazienza di leggere fin qui

[Dane]

sostanzialmente ogni chip/scheda nell'elettronica odierna e specialmente nel mercato dei pc è progettato per durare un tot di anni.

Ovviamente i produttori non possono provare se veramente i componenti sopravviveranno fino alla durata di progetto, ma vengono venduti comunque. Poi possono accadere problemi del genere....se ovviamente sono tali.

se prendi una 9500 moddabile....con un po' di fortuna hai una 9700np/pro teoricamente identica.

[franklar]

Originariamente inviato da athanatos
fino a qualche tempo fa mi chiedevo:

Si è parlato a lungo della modifica. E le ipotesi più in auge sembrano quelle che vogliono le 9500 non modificabili dotate di procesori di "seconda scelta", con Pipeline rovinate o non funzionanti alla perfezione.


in realtà non sono le 4 pipe a non funzionare, ma il collegamento tra esse e l'unità Hyper-Z. In effetti la mia scheda con la mod si blocca del tutto, ma se uso dei bench in cui posso disattivare l'accesso allo Z-Buffer ( in particolare bench di fillrate ) allora la scheda va senza problema alcuno, le 4 pipe renderizzano correttamente ergo sono sane.

Il problema dello z-buffer è una vecchia conoscenza di chi cercava di moddare le Raddy 8500 LE in 8500 lisce, ottenendo in molti casi artefatti analoghi a quelli delle 9500. Chissà perchè alla ATI hanno avuto tanti casini con lo z-buffer... boh ?

[athanatos]

Originariamente inviato da franklar
in realtà non sono le 4 pipe a non funzionare, ma il collegamento tra esse e l'unità Hyper-Z. In effetti la mia scheda con la mod si blocca del tutto, ma se uso dei bench in cui posso disattivare l'accesso allo Z-Buffer ( in particolare bench di fillrate ) allora la scheda va senza problema alcuno, le 4 pipe renderizzano correttamente ergo sono sane.


Ho imparato qualcosa.
Quindi di un difetto hardware comunque si tratterebbe?
Si tratterebe di capire se è un difetto voluto (per ottenere delle 9500... anche in questo caso sarebbe troppo fantasioso pensare ad un "difetto" indotto e voluto (magari dando una sovratensione ad una coppia di pin)?), o incidentale (di progettazione o di realizzazione).
Immagino comunque che disattivare l'accesso allo Z-Buffer sia una cosa che non è prevista nel normale utilizzo della scheda (o si può fare anche al di fuori degi spcecifici programmi di bench?). Inoltre, così a naso, non so se porebbe valer la pena abilitare le 4 pipeline per poi non sfruttare l'architettura dell'Hyper-Z (che in caso si scene complesse, ma pare faccia risparmiare molto, forse anche più di quello che si guadagnerebbe)


Il problema dello z-buffer è una vecchia conoscenza di chi cercava di moddare le Raddy 8500 LE in 8500 lisce, ottenendo in molti casi artefatti analoghi a quelli delle 9500. Chissà perchè alla ATI hanno avuto tanti casini con lo z-buffer... boh ?

Non ricordo: tra 8500LE e lisce non era solo una differenza di clock? (sono schede di cui non mi ero mai interessato). Ad ogni modo si tratterebbe comunque di problemi fisici e non risolvibili semplicemente metendo a punto i driver (o le loro parti inerenti alla gestione di questa sezione del processore)? Se fosse un problema/ostacolo software allora si potrebbe fare avanti una delle altre ipotesi che avevo letto in giro, e cioè che l'inibizione delle 4 pipeline avvenga tramite bios e/o driver. Ergo i driver modificati non sarebbero modificati a sufficienza? Ma allora perché alcune schede vanno ed altre no? E perché alcune si modificavano semplicemente spostando una microscopica resistenza in SMD ed altre no?

Visto così sembrerebbe porprio un problema hardware, forse nemmeno tanto preventivato o voluto.

[franklar]

Per iniziare, la versione dei fatti ormai considerata più attendibile è che siano le 4 pipe di rendering ad essere "rotte". Io però ho visto che in un bench in cui c'è una enorme sovrapposizione di poligoni le 9700 fanno 100 fps e le 9500 ne fanno 10, vuol dire che l'Hidden surface removal ( HSR, rimozione dei poligoni nascosti ) funziona sulle 9700 e non sulle 9500.
Inoltre nei test di puro fill rate ( senza uso di z-buffer ) quasi TUTTE le 9500 funzionano moddate.

L'architettura del chip inoltre è tale che l'unità deputata alle operazioni di antialiasing si frappone tra le pipeline di rendering e la z-unit, e a seconda che si attivi o meno l'antialiasing spesso le schede moddate si comportano in maniera molto diversa.

La conclusione a cui sono arrivato io quindi è che ATI abbia avuto dei problemi nelle interconnessioni tra la z-unit e le pipes di rendering. Non credo che tutto ciò sia voluto, certo è strano che questi problemi siano durati dal R200 all'R300 ( e anche le 9800SE si comportano allo stesso modo ).




Le 8500 LE non solo avevano clock più basso, ma anche l'HyperZ disativato. Attivandolo, si avevano spesso degli artefatti. Ho cercato ( e forse non solo io ) per molto tempo di disattivare completamente l'HyperZ ( e quindi l'HSR ) sui driver moddati per le 9500, ma non è stato possibile, anche perchè ATI ha usato un sistema diverso da quello usato con le 8500. Dato che comunque nessuno mi ha dato una mano, visto che i modders ( e in particolare l'amico Unwinder, autore di Rivatuner ) sono tutti impegnati sa tempo sulle schede di nuova generazione, non rimane che tenerci le 9500 senza mod. :(



E perché alcune si modificavano semplicemente spostando una microscopica resistenza in SMD ed altre no?

quella resistenza permetteva di flashare il bios delle 9700 sulle 9500, invece di fare la modifica software. Cmq questo non ha influenza sugli artefatti.

in definitiva:

1) se il driver rileva una 9700/9800, originale o con modifica hardware o software, attiva le 8 pipeline e l'unità HyperZ è completamente funzionale.

2) se rileva una 9500 non-pro o una 9800SE, attiva solo 4 pipeline e solo le basilari funzioni di z-buffering, in particolare non esiste alcun tipo di HSR.


Spero di non aver detto vaccate :D, cmq. è tutto quello che ho letto in giro più quello che so per esperienza, avendo personalmente disassemblato e provato modifiche e studiato quelle di Unwinder e Wizzard fin dai Catalyst 3.8.

[athanatos]

ricapitolando, fammi vedere se ho capito:

In sostanza qualche problemino hardware nel progetto ce l'hanno avuto. Più che nel progetto del R300, nel progetto del comparto Hyper-Z, magari ripreso di volta in volta nei vari chip dal R200 in poi (magari i tempi stretti imposti dalla presenza di un concorrente hanno fatto sì che non si riuscisse a concentrarsi e poter risolvere i problemi).

In pratica mi stai dicendo che non sono le fantomatiche 4 pipeline mancanti a far scendere le prestazioni, ma ben altre features, forse ben più importanti. in pratica 9500 liscie, 9800 SE (e anche 8500 LE), sono altrettanto potenti delle sorelle maggiori, ma poco efficienti a confronto (andandosi a calcolare tutto... anche quello che non si vede...).

Resto ancora nel dubbio.
Secondo te può davvero trattarsi solo di trovare la modifica giusta nel software? o nel flash del bios giusto? (o in una loro giusta combinazione?) O l'aleatorietà del successo della modifica risiede davvero in differenze hardware? (forse tu mi stai spegando e io non riesco a capire. Se fosse così chiedo scusa)

Ti ringrazio per le delucidazioni (ho l'impressione che a pochi altri interessi tutto ciò), e vedo altresì che te ne intendi parecchio (parli perfino di decompliazione... e l'ingegneria del software non è proprio il mio campo)

[Aketaton]

Finalmente un 3d come dio comanda :)

Grazie ad entrambi:)

[franklar]

da leggere:

http://www.digit-life.com/articles2/radeon/r9500-9700-dx9-p2.html


interessante il test HIDDEN SURFACE REMOVAL, un pò sotto la metà della pagina:





http://www.ixbt.com/video2/images/dx9-syn/hsr-d5.jpg

Isn't it shocking?

1. The HSR ...

2. It does work (HyperZ) in all the RADEON 9700 and RADEON 9500 PRO chips and demonstrates a perfect performance. But it is not supported in all RADEON 9500 chips! It's disabled, and probably on the driver level again. Why? Maybe, for creation of an additional difference in real applications? But the more believable version is that there are some defects in the die, and that is why they are used for cards on the RADEON 9500. Besides, to make performance lower relative to the RADEON 9500 PRO and 9700, such dies have half of their pipelines disabled. In the first part we discussed the problem of turning the RADEON 9500 into RADEON 9700 (9500 PRO) with the RivaTuner, i.e. on the software level. The following events showed that it's not so smooth as we wanted it to be. First of all, not all R9500 chips work without artefacts after the redesigning, about 28% have bugs which indicate some problems in the HyperZ unit. Isn't it the unit that controls the HSR? I think that ATI disables the crippled HSR unit on the software level with half of the pipelines and then uses such chips as RADEON 9500.

[franklar]

http://www.ixbt.com/video2/images/r300/r300-scheme.png



quin non si vede bene, cmq si intuisce che attivando l'antialiasing il chip processa le immagini prima nell'unità smoothvision e poi nella hyperz-unit; il che spiega perchè molte schede hanno artefatti senza filtri attivati, che spariscono appena si attiva l'antialiasing.

[franklar]

Originariamente inviato da athanatos
ricapitolando, fammi vedere se ho capito:



In pratica mi stai dicendo che non sono le fantomatiche 4 pipeline mancanti a far scendere le prestazioni...


oh... le fanno scendere eccome ! :D

il problema è che ATI aveva un sacco di schede con l'HyperZ rotto, ma vendendole con il solo HyperZ disattivato le 9500 con 8 pipelines sarebbero andate ( tenuto conto anche del clock inferiore ) al massimo un 20% più lente. Dato che dovevano costare la metà e andare la metà, hanno tagliato le 4 pipes e dimezzato le prestazioni.

Tuttavia credo che solo in alcuni casi gravissimi fossero le pipes ad essere malfunzionanti.( tipo: ad alcuni il PC nemmeno si avviava dopo la mod )



Originariamente inviato da athanatos
Secondo te può davvero trattarsi solo di trovare la modifica giusta nel software?


Sbloccare le pipes aggiuntive nei drivers non è difficilissimo, tanto che ATI ha introdotto delle ridicole routines di protezione, prontamente aggirate :asd:

Nessuno ha provato seriamente a manipolare la gestione dell'HyperZ e in particolare dell'HSR, o meglio, ci ho provato io, ma senza grossi esiti ( in compenso ho scoperto un terzo modo per sbloccare le pipes :D ).

Purtroppo i drivers, una volta disassemblati, si trasformano in un centinaio di MB di codice assembly e io non sono certo al livello di Unwinder, mi ci vorrebbero secoli :(

[athanatos]

Ho visto l'articolo, e me lo leggerò con calma. Comunque il divario che c'è tra la configurazione del R300 su 9500 lisce e su altre configurazioni è notevole.

Originariamente inviato da franklar
il problema è che ATI aveva un sacco di schede con l'HyperZ rotto, ma vendendole con il solo HyperZ disattivato le 9500 con 8 pipelines sarebbero andate ( tenuto conto anche del clock inferiore ) al massimo un 20% più lente. Dato che dovevano costare la metà e andare la metà, hanno tagliato le 4 pipes e dimezzato le prestazioni.


Io pensavo che l'HyperZ fosse in grado di fare molto più di un 20%, soprattutto nelle scene complesse (non ho la più pallida idea di come funzioni l'algoritmo di calcolo, ma pensavo che i più grezzi calcolassero tutta la scena, oggetti nascosti compresi che poi vengono coperti da quelli in primo piano... mi immagino una collina che nasconda una città o foresta...

Certo comunque che se fosse davvero possibile disbilitare solo l'HyperZ, sarebbe una pacchia. Non solo, se nel post di prima mi dici che spesso basterebbe attivare i filtri per far saprire artefatti, no nposso che confessarti che mi sta per arrivare una 9500 liscia (dichiarata guasta/non modificabile causa artefatti).

Si vede che non avevo capito bene il discorso. Pesavo che l'HyperZ avesse un ruolo più importante nel processo, soprattutto in caso di scene complesse.
(io chiedo, ma devo ammetere che non so neanche come funzioni una GPU, da che parti sia composta, e come funzioni il processo di formazione di una immagine 3D sullo schermo. L'argomento è molto interessante, ma forse un po' troppo lungo per un non addetto ai lavori)



Sbloccare le pipes aggiuntive nei drivers non è difficilissimo, tanto che ATI ha introdotto delle ridicole routines di protezione, prontamente aggirate :asd:

Nessuno ha provato seriamente a manipolare la gestione dell'HyperZ e in particolare dell'HSR, o meglio, ci ho provato io, ma senza grossi esiti ( in compenso ho scoperto un terzo modo per sbloccare le pipes :D ).

Purtroppo i drivers, una volta disassemblati, si trasformano in un centinaio di MB di codice assembly e io non sono certo al livello di Unwinder, mi ci vorrebbero secoli :(

certo che mettere le mani in un centinaio di MB di codice (assembler per di più), pur non essendo io un programmatore, non suona tanto facile (ma come fate a racapezzarvi? e dire che un libro come la Bibbia sarà già lui da solo qualche MB...).
So di andare OT, ma la decompilazione mi incuriosisce (solo a livello di curiosità... prima infatti bisognerebbe essere capaci di scrivere e compliare...)

Per ora non posso che ringraziarti per la cortesia e la premura nelle spiegazioni/argomentazioni.

[franklar]

Originariamente inviato da athanatos

Io pensavo che l'HyperZ fosse in grado di fare molto più di un 20%, soprattutto nelle scene complesse (non ho la più pallida idea di come funzioni l'algoritmo di calcolo, ma pensavo che i più grezzi calcolassero tutta la scena, oggetti nascosti compresi che poi vengono coperti da quelli in primo piano... mi immagino una collina che nasconda una città o foresta...


più che altro l'HZ consente di risparmiare molta bandwidth di memoria, rispetto ad altri metodi più tradizionali come l'earlyZ... cmq i moderni motori grafici sono ottimizzati e evitano di renderizzare tutta una città se coperta da una collina ;)

cmq indagando meglio pare che sulla 9500 l'hyperZ in parte funzioni, ma ad esempio una sua parte importante come lo HierarchicalZ è completamente bacata ( almeno sulla mia sk. ) e disabilitata di default.





certo che mettere le mani in un centinaio di MB di codice (assembler per di più), pur non essendo io un programmatore, non suona tanto facile (ma come fate a racapezzarvi?


giunti ai Catalyst 4.9beta, il driver miniport disassemblato ( non decompilato, magari... :D ) "pesa" 8 MB, il driver Direct3D è sui 19 MB e quello OGL 61 MB !!!

se interessa, cercati questi software: Windasm e Perdr.




(ma come fate a racapezzarvi? )

la difficoltà maggiore sta nelle routine che ATI inserisce volontariamente per camuffare dati importanti, come Device ID, registri interni della VPU e chiavi del registro di Windows.

Per fortuna si possono comparare i drivers recenti con le vecchie versioni, che hanno molte meno protezioni.

SEGUE ESEMPIO:

[franklar]

ecco come appare la routine che attiva le 4 o 8 pipeline nei Catalyst 2.3:



000576B1 cmp eax,00004144h ==> Device ID della Radeon 9500 :D
000576B6 mov ecx,00040000h
000576BB jz 000576D2h ==> confronto con la scheda attuale
000576BD cmp eax,00004145h
000576C2 jz 000576D2h
000576C4 cmp eax,00004146h
000576C9 jz 000576D2h
000576CB cmp eax,00004147h
000576D0 jnz 000576D8h

* Referenced by a (U)nconditional or (C)onditional Jump or (c)all at Address:
| 000576BB(C), 000576C2(C), 000576C9(C)
|
000576D2 or [esi+0000011Ch],ecx

* Referenced by a (U)nconditional or (C)onditional Jump or (c)all at Address:
| 000576D0(C)
|
000576D8 test ecx,[esi+0000011Ch]
000576DE jz 000576F4h
000576E0 push 01h
000576E2 push 000010B2h
000576E7 push ebx
000576E8 call 00056526h
000576ED mov eax,00010011h ==> 4 pipeline :mad:
000576F2 jmp 00057706h

* Referenced by a (U)nconditional or (C)onditional Jump or (c)all at Address:
| 000576DE(C)
|
000576F4 push 03h
000576F6 push 000010B2h
000576FB push ebx
000576FC call 00056526h
00057701 mov eax,00010017h ==> 8 pipeline :D

* Referenced by a (U)nconditional or (C)onditional Jump or (c)all at Address:
| 00092FAF(U)
|
00092FC8 push eax
00092FC9 mov edi,00001006h ==> registro VPU che controlla le pipe. Ci scrive dentro 10017 o 10011.

00092FCE push edi
00092FCF push ebx
00092FD0 mov [ebp+00000008h],eax
00092FD3 call 0008E612h



dai Catalyst 3.0 non appare più alcun riferimento esplicito ai Device ID, quindi quella parte di codice è molto meno appariscente :)






ecco come si abilitava lo HierarchicalZ in OGL con i Catalyst 2.1:



* Possible string reference 692619F0h "enableHierarchicalZ"
|
69164E61 mov edx,692619F0h
69164E66 mov ecx,ebp
69164E68 mov [esi+000170BCh],eax
69164E6E call 6915E080h



e come il tutto è stato truccato fin dai Catalyst 2.3:


* Possible string reference 69595670h "gdSeq1cyMV7EN"
|
693F7918 mov edx,69595670h
693F791D lea ecx,[esp+0000001Ch]
693F7921 mov [ebp+00000654h],eax
693F7927 call 690A0310h