di  -  mercoledì 3 novembre 2010

Ha suscitato molto scalpore e sollevato parecchie polemiche la presentazione di un nuovo benchmark basato su H.A.W.X. 2, pensato per mettere alla frusta in particolare la tecnica di tessellation introdotta con le DirectX 11 da Microsoft.

In una recente notizia del nostro sito principale e in estrema sintesi, pare che Ubisoft abbia preferito non implementare una soluzione proposta da AMD, utilizzandone invece un’altra che penalizza le sue schede e che, invece, funziona molto bene su quelle della concorrenza.

E’ possibile che Nvidia abbia contributo allo sviluppo del gioco, a livello tecnico e/o economico, ma cosa ci sia realmente sotto non è dato saperlo, per cui è bene fermarsi alle mere ipotesi. In ogni caso i rapporti di esclusiva fra aziende non sono eventi nuovi né sanzionabili, a meno che non mettano a rischio la concorrenza nel mercato (e non mi pare questo il caso: il gioco girerà ugualmente, anche se con un frame rate inferiore).

AMD ha fatto sapere che provvederà con una soluzione ad hoc, intercettando l’esecuzione del gioco a livello di driver, probabilmente con operazioni di shader replacement, cioè sostituendo sequenze di codice eseguite dalla GPU con delle versioni ottimizzate per le sue schede.

Anche questa non è una novità, visto che si tratta di escamotage ben noto da anni, a cui hanno fatto ricorso entrambe le aziende a seconda delle occasioni e delle esigenze. Roba che ha fatto gridare allo scandalo certi utenti puristi (o puritani?), ma non necessariamente illecita o deprecabile.

Lo scandalo può derivare dalla convinzione che un gioco non debba essere “toccato” (modificato) in alcun modo, per cui i driver della scheda grafica non dovrebbero alterarne assolutamente il codice degli shader predisposto allo scopo dalla software house l’ha sviluppato.

Questa visione romantica e ingenua non può certamente conciliarsi con la realtà, specialmente con quella di matrice prettamente tecnica. Il 3D, infatti, è per definizione una modellazione (riduttiva) di ciò che ci circonda o addirittura di mondi del tutto nuovi, ed è necessariamente frutto di compromessi.

La stessa realizzazione di un gioco lo è, in quanto non esiste un unico e solo engine 3D che fa girare tutti i giochi, ma una moltitudine che presenta pregi o difetti a seconda degli obiettivi che la software house s’era prefissa. Giusto per essere chiari, un simulatore di volo ha sicuramente esigenze molto diverse da un gioco di ruolo, e l’engine sarà scritto di conseguenza.

I driver partono, quindi, da una situazione in cui chi ha scritto il gioco ha già provveduto ad approssimazioni varie, tirando anche fuori dal cappello trucchetti e idee, atti a rendere qualcosa che andrà a stimolare la visione del giocatore.

Pertanto ritoccare ulteriormente il codice in modo da ottenere prestazioni migliori sul proprio hardware è un’operazione legittima, oltre che auspicabile nello specifico, purché l’esperienza di gioco non venga modificata in maniera percepibile dall’utente finale.

Purtroppo proprio l’esperienza ci insegna che a volte ciò non accade, in quanto le sostituzioni effettuate possono introdurre artefatti o alterazioni sensibili dei dati, e anche questo si può dire tanto di Ati/AMD quanto di Nvidia . Anzi, con 3DMark penso si sia andato decisamente oltre il concetto di ottimizzazione, vista la rilevanza che viene data a quest’applicazione.

Non sempre, infatti, le nuove soluzioni sono matematicamente equivalenti a quelle originali, ma questo non è per forza di cose un male, proprio perché abbiamo a che fare con delle approssimazioni. Lo è, come già detto, se viene alterato il risultato finale in maniera percepibile.

Tornando ad H.A.W.X. 2, per forza di cose AMD dovrà adottare una soluzione che presenterà risultati diversi dal codice originale, perché sappiamo bene che l’unità di tessellation integrata nelle sue GPU presenta delle buone prestazioni a bassi valori di tessellation, mentre crollano a livelli più elevati.

Certamente stracciarsi le vesti pretendendo che AMD offra ugualmente una tessellation elevata ha poco senso, perché produrre tantissimi poligoni che coprono singoli pixel o addirittura lo stesso pixel non porta incrementi nella qualità visiva. Pertanto un certo margine di scostamento dal risultato originale non sarà deprecabile, ma l’utente finale dovrà rimanere appagato dalla resa visiva (e dal frame rate ottenuto).

Non v’è dubbio che AMD in questo momento si trova in una posizione difficile riguardo alla tecnica di tessellation, e pur avendola migliorata con la nuova famiglia 6800 non offre risultati comparabili a quelli delle GPU Fermi di Nvidia.

Può procedere ancora con la stessa tecnica di shader replacement per i prossimi giochi, ma sarebbe meglio spendere delle risorse per una soluzione più generale, magari sfruttando la potenza di calcolo dei numerosissimi (rispetto alla concorrenza) stream processor che la sua architettura mette a disposizione (fermo restando che è diversa da quella di Fermi), in attesa di una soluzione migliore a livello hardware (se ha senso farlo).

Lamentarsi e battere i piedi, però, non lo trovo accettabile. Si tratta oggettivamente di un problema suo e che deve provvedere a risolvere in prima persona, se vuole rimanere competitiva anche in questo campo. Nvidia da questo punto di vista ha semplicemente scelto di spendere i suoi soldi nella maniera che ritiene più conveniente, e nulla le si può rinfacciare.

Agli utenti non rimangono che tre soluzioni: non comprare le sue schede se sono convinti che senza tessellation non si possa vivere, attendere i nuovi driver di AMD, o semplicemente esercitare la migliore opzione che hanno come consumatori, cioè non comprare giochi come H.A.W.X. 2 e facendo sapere a Ubisoft che non intendono accettare la sua presa di posizione.

Quest’ultima è sicuramente meno praticabile, perché manca una solida coscienza collettiva dei consumatori. Si tratta di una questione prettamente culturale. D’altra parte esiste anche gente che si permette di giudicare una scheda grafica sulla base di un solo gioco o, peggio ancora, di un benchmark sintetico…

28 Commenti »

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.

  • # 1
    asdolo
     scrive: 

    Assolutamente in disaccordo per un semplice motivo.
    un Benchmark è un prodotto che dovrebbe essere in grado di MISURARE le prestazioni di una certa serie di operazioni/tasks.
    Se i termini in cui il benchmark stesso è stato progettato sono PARZIALI e a favore di una certa architettura piuttosto che di un’altra, allora non ha più il significato di benchmark ma diventa uno strumento nelle mani di una certa azienda a scopo pubblicitario.
    Un conto è un gioco, che per motivi di tempo o facilità di programmazione o quant’altro è stato scritto per sfruttare un’architettura piuttosto che un’altra (e anche qui la cosa è opinabile), ma un benchmark NON se lo può permettere.
    Oltretutto lede sì la concorrenza del mercato, xkè un benchmark di una società terza dovrebbe essere imparziale, altrimenti è pura semplicità mirata.

  • # 2
    mede
     scrive: 

    si ma per serietà questo lavoro di ottimizzazione dovrebbe farlo chi relizza il gioco e non rilasciare una versione del gioco che gira di merda in una percentuale di PC e aspettarsi che sia il costruttore di schede video a dover spendere soldi per ottimizzarlo. mi pare una strada del cacchio che se portata all’esasperazione finirebbe a portarci in un’era di caos totale. a sto punto facessero le cose chiare e non supportassero dichiaratamente una tale scheda o chip. e si prendessero la responsabilità dell’azione anche di fronte all’antitrust. questo ostracismo a metà è solo a discapito dell’utente, e decisamente poco serio. anche perchè poi alla fine daranno la colpa alle schede video, e chi non ci capisce nulla penserà semplicemente che le schede amd fanno schifo. e tutto questo per mettere il logo nvidia e permettere al produttore di acchiappare la mazzetta da nvidia.
    è immorale perchè non stiamo parlando di ps3 o xbox in cui ognuno propone il suo pacchetto ed è tutto molto chiaro e evidente, stiamo parlando di fare questa politica a spese dell’utente, che per non avere problemi sarà spinto a prendere la nvidia che salirà di prezzo (anche se sarà di qualità inferiore) mentre la scheda amd dovrà essere abbassata di prezzo per essere venduta senza margine andrà benissimo ma è poco compatibile coi giochi (che è poi l’unico motivo per cui te la compri normalmente…)

  • # 3
    goldorak
     scrive: 

    Con il ragionamento della Ubisoft, le diretx o le opengl non dovrebbero proprio esistere. Si ritorna ai tempi delle api proprietarie tipo quelle della 3dfx. Chi si ricorda, cerano giochi fatti per le schede 3dfx e poi tutto il resto. Che bello quando 3dfx falli. Microsoft ha fatto una cosa eccezionale astraendo dal hardware e dando alle software house la possibilita’ di sviluppare su un api hardware agnostica. Ne hanno giovato i consumatori.
    Ora invece visto che Nvidia non riesce piu’ a competere ad armi pari contro ATI si torna a modi di fare “obsoleti”. Figli di un tempo ormai revoluto. E uno schifo, e la Ubisoft dovrebbe essere criticata aspramente, altro che’ tesserne le lodi.

    Se Ubisoft vuole api proprietarie legate al hardware che sviluppi soltanto su console. Tanto ormai quello che produce per pc e’ soltanto me..a.

  • # 4
    ares17
     scrive: 

    Hai perfettamente ragione in tutto.
    Ma mi chiedo come mai la triade Moggi-Giraudo-Bettega sono stati condannati per aver scelto di spendere soldi non nell’acquistare giocatori, o come mai la stessa cosa è successa ad intel con le “promozioni” e le relative osservazioni degli organi competenti riguardo il suo compilatore.
    Continua a trattare argomenti tecnici di informatica, ma tralascia di tentare di adottare posizioni riguardo la legalità o moralità di un’azione nel settore grafico.
    Se si verrebbe a scoprire che quello che è accaduto non sia dovuto all’incapacità dei programmatori di ubisoft di sfruttare al meglio l’hardware disponibile sul mercato ma ad una precisa intenzione di favorire un approcio architetturale a sfavore di un’altro (concettualmente quasi agli antipodi) rischi di essere marchiato a vita come Fanboy.

  • # 5
    Marco
     scrive: 

    Se si verrebbe a scoprire che quello che è accaduto non sia dovuto all’incapacità dei programmatori di ubisoft di sfruttare al meglio l’hardware disponibile sul mercato ma ad una precisa intenzione di favorire un approcio architetturale a sfavore di un’altro (concettualmente quasi agli antipodi) rischi di essere marchiato a vita come Fanboy.

    Se si *venisse* a scoprire che quello che è accaduto non *è* dovuto all’incapacità dei programmatori di ubisoft di sfruttare al meglio l’hardware disponibile sul mercato ma ad una precisa intenzione di favorire un approcio architetturale a sfavore di un’altro (concettualmente quasi agli antipodi) *rischieresti* di essere marchiato a vita come Fanboy.

  • # 6
    ares17
     scrive: 

    @Marco
    Se mi inviassi la tua mail ti passerei i miei post in modo che me li possa revisionare ed evitare questi strafalcioni ;)

  • # 7
    Cesare Di Mauro (Autore del post)
     scrive: 

    @asdolo:

    Assolutamente in disaccordo per un semplice motivo.
    un Benchmark è un prodotto che dovrebbe essere in grado di MISURARE le prestazioni di una certa serie di operazioni/tasks.
    Se i termini in cui il benchmark stesso è stato progettato sono PARZIALI e a favore di una certa architettura piuttosto che di un’altra, allora non ha più il significato di benchmark ma diventa uno strumento nelle mani di una certa azienda a scopo pubblicitario.

    E’ possibile, ed è legittimo, visto che lo sviluppo di un gioco richiede parecchi investimenti da parte della software house, e se questa ha la possibilità di farsi realizzare parte del codice oppure di essere finanziata, non vedo perché non dovrebbe poterlo fare.

    Come ho già scritto nell’articolo, gli accordi di esclusiva nell’ambito dei videogiochi non sono roba recente. Hai mai visto girare Halo sulla PS2? Io no.

    Riguardo al benchmark in questione, è stato scritto espressamente per stressare il tessellator: è scritto a chiare lettere. Ma in condizione di un fattore elevato, le architetture di AMD sono svantaggiate, come ben sappiamo.

    Un conto è un gioco, che per motivi di tempo o facilità di programmazione o quant’altro è stato scritto per sfruttare un’architettura piuttosto che un’altra (e anche qui la cosa è opinabile), ma un benchmark NON se lo può permettere.

    Può essere opinabile quanto vuoi, ma è realistica: esistono risorse limitate nello sviluppo di un gioco, e soprattutto scadenze alle porte. Per cui fare delle scelte, anche dolorose, può capitare. Ed esistono anche le esclusive, come già detto.

    Poi se il benchmark in questione sfrutta l’engine del gioco che arriverà sugli scaffali, rappresenta qualcosa di più di un 3DMark che, invece, non viene utilizzato in nessun gioco reale.

    Oltretutto lede sì la concorrenza del mercato, xkè un benchmark di una società terza dovrebbe essere imparziale, altrimenti è pura semplicità mirata.

    Esistono ed esisteranno sempre giochi che sfrutteranno meglio certe architetture piuttosto che altre. Anche a fronte di foraggiamenti delle aziende, ed eventualmente di esclusive.

    La concorrenza dove verrebbe meno? Hai mai chiesto a Nintendo come mai non rilascia Mario Galaxy per le altre console e il PC? Il mercato non mancherebbe, ma… non lo fa.

    @mede:

    si ma per serietà questo lavoro di ottimizzazione dovrebbe farlo chi relizza il gioco e non rilasciare una versione del gioco che gira di merda in una percentuale di PC e aspettarsi che sia il costruttore di schede video a dover spendere soldi per ottimizzarlo. mi pare una strada del cacchio che se portata all’esasperazione finirebbe a portarci in un’era di caos totale. a sto punto facessero le cose chiare e non supportassero dichiaratamente una tale scheda o chip.

    Anche questo viene fatto. Le software house tengono conto della diffusione dell’hardware nel mercato per stabilire il target dei giochi.

    e si prendessero la responsabilità dell’azione anche di fronte all’antitrust.

    Non sarebbe male come idea. Magari potrei finalmente veder girare giochi come Dirt 2 sulla mia Radeon 8500…

    questo ostracismo a metà è solo a discapito dell’utente, e decisamente poco serio. anche perchè poi alla fine daranno la colpa alle schede video, e chi non ci capisce nulla penserà semplicemente che le schede amd fanno schifo. e tutto questo per mettere il logo nvidia e permettere al produttore di acchiappare la mazzetta da nvidia.

    Si chiama pubblicità. E dalle mie parti non te la fanno gratuitamente. AMD non potrebbe fare lo stesso?

    Per il resto penso sia una questione di cultura e informazione, a cui purtroppo non ha accesso la massa.

    è immorale perchè non stiamo parlando di ps3 o xbox in cui ognuno propone il suo pacchetto ed è tutto molto chiaro e evidente, stiamo parlando di fare questa politica a spese dell’utente, che per non avere problemi sarà spinto a prendere la nvidia che salirà di prezzo (anche se sarà di qualità inferiore) mentre la scheda amd dovrà essere abbassata di prezzo per essere venduta senza margine andrà benissimo ma è poco compatibile coi giochi (che è poi l’unico motivo per cui te la compri normalmente…)

    Citi PS3 e XBox, ma dovresti sapere che anche lì la situazione non è molto diversa. Non ci sono forse le esclusive (anche temporali)? E giochi multipiattaforma che girano meglio su certe piattaforme piuttosto che su altre?

    @goldorak:

    Con il ragionamento della Ubisoft, le diretx o le opengl non dovrebbero proprio esistere. Si ritorna ai tempi delle api proprietarie tipo quelle della 3dfx. Chi si ricorda, cerano giochi fatti per le schede 3dfx e poi tutto il resto. Che bello quando 3dfx falli. Microsoft ha fatto una cosa eccezionale astraendo dal hardware e dando alle software house la possibilita’ di sviluppare su un api hardware agnostica. Ne hanno giovato i consumatori.

    L’esempio non mi sembra che calzi. La guerra fra Glide, OpenGL e altre API / librerie erano tutt’altra cosa.

    Qui si tratta di confrontare le implementazioni offerte dai produttori di schede video sulla base di API comuni.

    Hai detto bene: Microsoft ha fatto un lavoro eccezionale con le DirectX, in particolare con la loro completa riscrittura a partire dalla versione 10, ma non ha fissato rigidamente le implementazioni dei driver.

    Attualmente la “guerra” si gioca proprio su questo fronte, e su quello del valore aggiunto di roba come CUDA, OpenCL, PhysX, ecc. E non poteva essere altrimenti.

    Per lo meno la situazione è di gran lunga migliorata rispetto alle OpenGL e al loro famigerato meccanismo delle estensioni, che comportavano obbligatoriamente code path diversi per le diverse famiglie di GPU. Doom3 docet.

    Ora invece visto che Nvidia non riesce piu’ a competere ad armi pari contro ATI si torna a modi di fare “obsoleti”. Figli di un tempo ormai revoluto.

    Quei modi non sono mai morti. Le esclusive ne sono una chiara testimonianza, così come il caso citato nell’articolo, appunto.

    E uno schifo, e la Ubisoft dovrebbe essere criticata aspramente, altro che’ tesserne le lodi.

    Non mi sembra che qualcuno l’abbia fatto.

    Se Ubisoft vuole api proprietarie legate al hardware che sviluppi soltanto su console. Tanto ormai quello che produce per pc e’ soltanto me..a.

    Qui non c’è nessuna API proprietaria, come dicevo prima.

    La partita ormai si gioca tutta sulle implementazioni. Le architetture proposte da Nvidia e AMD sono molto diverse fra di loro, e a seconda degli scenari hanno punti di forza e di debolezza.

    Lo dimostra il caso in oggetto. Ma non c’è nessuno che stia implementando qualcosa di diverso.

    Ubisoft ha deciso di fare pesante uso del tessellator. Caratteristica standard delle DirectX 11. Che Nvidia e AMD implementano in maniera diversa. Ottenendo risultati diversi.

    Sic et simpliciter.

    @ares17:

    Hai perfettamente ragione in tutto.
    Ma mi chiedo come mai la triade Moggi-Giraudo-Bettega sono stati condannati per aver scelto di spendere soldi non nell’acquistare giocatori,

    Ti consiglio di astenerti dal fare affermazioni che potrebbero costarti una denuncia per diffamazione (non da parte mia, s’intende: non sarei parte lesa e non ne ho interesse), a meno che non hai sentenze che lo attestino fino all’ultimo grado di giudizio.

    o come mai la stessa cosa è successa ad intel con le “promozioni” e le relative osservazioni degli organi competenti riguardo il suo compilatore.

    Ricordi male. Ecco qui l’ultimo link sull’argomento: http://www.businessmagazine.it/news/intel-e-ftc-i-dettagli-dell-accordo_33449.html

    “infine viene fatta richiesta di informare gli sviluppatori software del fatto che il compilatore Intel va a discriminare tra processori Intel e non-Intel, con la possibilità di non sfruttare appieno le caratteristiche di questi ultimi. Intel dovrà inoltre rimoborsare tutte le software house che intendono ricompilare il proprio software impiegando un compilatore non-Intel.”

    Come vedi questo NON dimostra che Intel non possa realizzare e vendere compilatori ottimizzanti esclusivamente per le sue architetture. Può farlo, ma è obbligata a informarne gli acquirenti.

    Alla fine è sempre un problema di cultura…

    Continua a trattare argomenti tecnici di informatica, ma tralascia di tentare di adottare posizioni riguardo la legalità o moralità di un’azione nel settore grafico.

    Questa rubrica ha un titolo ben preciso. E l’articolo in questione è perfettamente in linea con gli argomenti trattati.

    Se si verrebbe a scoprire che quello che è accaduto non sia dovuto all’incapacità dei programmatori di ubisoft di sfruttare al meglio l’hardware disponibile sul mercato ma ad una precisa intenzione di favorire un approcio architetturale a sfavore di un’altro (concettualmente quasi agli antipodi) rischi di essere marchiato a vita come Fanboy.

    Qui si ravvisano un paio di fallacie logiche:
    http://www.linux.it/~della/fallacies/spaventapasseri.html
    http://www.linux.it/~della/fallacies/pendio-scivoloso.html

    Tra l’altro è patetico un attacco del genere, quando nemmeno sai che GPU montano i miei PC. Ma immagino che dopo la mia “difesa” (sic!) di Intel, mi considererai anche un fanboy di quest’azienda.

  • # 8
    [D]
     scrive: 

    Secondo me la cosa si può risolvere facilmente così: sia sulla scatola che all’avvio del gioco si piazza un bel logo del tipo “plays better on nvidia/ati” eventualmente segnalando pure il modello di scheda consigliato così chi non ha la scheda “consigliata” è informato da subito che potrebbe rimetterci qualcosa.

    Diversamente se non fanno così (o si limitano alle tipiche righe scritte in piccolo) si meritano tutte le critiche del mondo e forse pure altro.

  • # 9
    kache
     scrive: 

    Il problema, come al solito, non è AMD, ma Ubisoft, che sono anni che adotta politiche contro l’utenza e contro i propri clienti.

  • # 10
    sire_angelus
     scrive: 

    non sono d’accordo…

    ci si batte per la net neutrality.. non dovrebbe essere corretto battersi per la Software neutrality?

    come le storie del compilatore icc… stesso problema.

  • # 11
    sire_angelus
     scrive: 

    ok.. letto meglio la risposta di mauro. e come sempre ci troviamo su posizioni molto diverse.

    il problema non é “ubisoft può fare come gli pare” ma: questo INUTILE utilizzo intensivo del tessellatore favorisce i giocatori? evidentemente nò, dato che le schede dx11 ati costituiscono il 50% del venduto da parecchi mesi… l’utilizzo indiscriminato fatto solo per far stallare le pipeline del tassellatore ati é una scelta che non riesco a perdonare alla software house, come i suoi assurdi drm… il primo hawx e il primo assassin’s creed era magnifico… no drm, andavano una meraviglia con le ati e tutto.. adesso invece… :(

  • # 12
    Cesare Di Mauro (Autore del post)
     scrive: 

    Se ti dicessi che mi trovo d’accordo su questo tuo ultimo commento, non cambierebbe nulla riguardo a quello, sempre tuo, precedente.

    Perché la software neutrality è impossibile da ottenere, per quanto esposto sia nell’articolo che nei commenti. Non puoi obbligare una software house che fonda sul lucro la sua esistenza, e che investe denaro sonante, ad accontentare tutti i possibili utenti / consumatori (perché poi significherebbe questo la “neutrality”: pretenderei un porting, ottimizzato, anche per AROS).

    Ha un budget, degli obiettivi, una scadenza (!!!), e deve necessariamente fare delle scelte. Anche farsi aiutare da qualcuno, eventualmente con accordi di esclusiva.

    A mio avviso gli unici che hanno il poter di far cambiare la situazione sono gli utenti, i consumatori, come dicevo alla fine dell’articolo. Sono loro che hanno il coltello dalla parte del manico, grazie al loro portafogli. Ubisoft senza i loro soldi non potrebbe sopravvivere, e dovrebbe per forza di cose scendere a compromessi, evitando certe scelte “poco felici” (un altro termine non posso usarlo perché mi devo automoderare :D).

    Ma manca proprio la cultura, la presa di coscienza, del consumatore.

    Una cosa la si potrebbe fare, e sarei d’accordo con [D]: pretendere che Ubisoft scriva a chiare lettere che il gioco gira meglio sulle schede Nvidia anziché su quelle AMD. Ma qui si aprirebbe il problema di elencare le configurazioni, e non credo che sarebbe sufficiente lo spazio a disposizione sulla scatola. Magari nel manuale interno, ma chi li legge i manuali (vedi recente articolo sull’argomento :D)?

  • # 13
    the solutor
     scrive: 

    Chissà perché quando ho letto il titolo dell’articolo avevo già capito chi l’aveva scritto ;-)

    Come al solito gli italiani si dividono in 2 di fronte a chi fa soldi in maniera spregiudicata.

    Chi è schifato dalle scorrettezze e chi è ammirato se non addirittura invidioso.

    A me capita di stare invariabilmente coi primi, a te coi secondi.

    Fine della discussione “tecnica”.

    Ma manca proprio la cultura, la presa di coscienza, del consumatore.

    Ma come, non eri tu quello che “il pc deve diventare un elettrodomestico” ?

    Che presa di coscienza ci deve essere nei confronti di un minipimer ?

  • # 14
    goldorak
     scrive: 

    Propongo di abolire le directx, anzi propongo di abolire del tutto le api che nascondono l’hardware (la piu’ grande conquista dai tempi del dos). Alla fin fine non servono a niente vero ?
    Ogni software house decidera’ come sfruttare l’hardware 3d, ogni software house decidera’ di implementare il supporto a una o due schede audio, ogni software house decidera’ di implementare il supporto a 2 interfacce di rete ed ogni gioco avra’ scritto sulla scatola (ati only or nvidia only).
    L’utente prendera’ coscienza di cio’ e per il grande piacere di Cesare di Mauro vedremo l’industria dei videogames andare in crash in un battibaleno.
    E ritorneremo allora al software rendering e al modo di fare sotto dos.
    Ve lo dico, e’ tutta una congiura di Tim Sweeney e di Intel. ^_^

  • # 15
    ares17
     scrive: 

    @cesare
    Ma manca proprio la cultura, la presa di coscienza, del consumatore.
    @
    Gia, perchè a leggere quello che scrivi sembra quasi che la cultura debba essere basata su una realtà distorta.
    Attento ad utilizzare il termine “lucro” al posto di “profitto”, generalmente il primo è termine peggiorativo del secondo.

    Riguardo la condanna alla triade: vorresti negare che non sia stata condannata dal tribunale sportivo della figc per aver anche investito € nell’acquisto di sim? (ps la giustizia sportiva si è pronunciata, quella civile è in atto).

    La ftc con quell’accordo ha imposto ad Intel un comportamento commerciale da tenere in futuro, non certo abbuonato eventuali illegalità che sono in corso di indagini (e la differenza è notevole), oltretutto tale accordo non mette al riparo Intel da eventuali ripercussioni legali in paesi extra-USA (vedo che continui a distorcere la realtà in modo da “acculturare” il consumatore che legge quello che scrivi alla tua personalissima visione delle cose)
    Riguardo al compilatore Intel da diverso tempo sotto osservazione dell’antitrust vedo che hai le idee chiare:
    L’impossibilità di dimostrare che il codice prodotto svantaggi volutamente i concorrenti fa si che (per la presunta innocenza dovuta a tutti) si consideri il codice super ottimizzato per le cpu Intel invece che pessimizzato per i concorrenti.
    Tutto questo è valido fintanto che non venga dimostrato il contrario (E da Intel non si può pretendere certo che spenda tempo nello sviluppo di un compilatore ottimizzato per le cpu dei concorrenti).
    Ps sono Juventino e nei miei case ho indifferentemente, a seconda dei prodotti disponibili in fase di acquisto, Intel, AMD, Nvidia, Via, Sis, ecc. Quindi cos’hai nel case non ti rende obiettivo ai miei occhi nelle tue esternazioni allo stesso modo che quello che ho io nei case non mi fa passare per obiettivo ai tuoi occhi (quello che ho scritto prima mi sembrava abbastanza chiaro, ma sei riuscito ugualmente a travisare. Attento però, moralità e lucro nello stesso discorso difficilmente vanno a braccetto)

  • # 16
    Cesare Di Mauro (Autore del post)
     scrive: 

    @the solutor:

    Chissà perché quando ho letto il titolo dell’articolo avevo già capito chi l’aveva scritto ;-)

    Idem quando ho visto che avevi scritto un commento: ne immaginavo già il contenuto. :P

    Come al solito gli italiani si dividono in 2 di fronte a chi fa soldi in maniera spregiudicata.

    Chi è schifato dalle scorrettezze e chi è ammirato se non addirittura invidioso.

    A me capita di stare invariabilmente coi primi, a te coi secondi.

    Fine della discussione “tecnica”.

    A me capita di andare un tantino oltre la mera logica booleana del “o sei con con me, o contro di me”.

    Fortunatamente da essere umano ho a disposizione logiche n-narie, con n > 2.

    Sarebbe stato sufficiente leggere i commenti per capire che non puoi partizionare rigidamente la gente in due fazioni opposte.

    Ma come, non eri tu quello che “il pc deve diventare un elettrodomestico” ?

    E continuo a sostenerlo.

    Che presa di coscienza ci deve essere nei confronti di un minipimer ?

    Non lo conosco, ma penso che il pendio scivoloso stia mietendo vittime di recente…

    @goldorak:

    Propongo di abolire le directx, anzi propongo di abolire del tutto le api che nascondono l’hardware (la piu’ grande conquista dai tempi del dos). Alla fin fine non servono a niente vero ?
    Ogni software house decidera’ come sfruttare l’hardware 3d, ogni software house decidera’ di implementare il supporto a una o due schede audio, ogni software house decidera’ di implementare il supporto a 2 interfacce di rete ed ogni gioco avra’ scritto sulla scatola (ati only or nvidia only).
    L’utente prendera’ coscienza di cio’ e per il grande piacere di Cesare di Mauro vedremo l’industria dei videogames andare in crash in un battibaleno.
    E ritorneremo allora al software rendering e al modo di fare sotto dos.
    Ve lo dico, e’ tutta una congiura di Tim Sweeney e di Intel. ^_^

    Sei troppo intelligente per non capire la differenza fra interfaccia e implementazione.

    Come già detto, l’interfaccia non è cambiata: le DirectX 11 sono quelle e non si scappa. Ma Microsoft NON PUO’ e NON DEVE obbligare i produttori a seguire delle linee guida anche nell’implementazione, a parte su un “controllo di qualità” (margini di tolleranza rispetto a risultati teorici e/o previsti).

    Difatti le architetture di Nvidia e AMD sono DX11, ma ovviamente sono MOLTO diverse. L’importante è che assolvano ai compiti che si sono prefissi. Ma nel farlo, sempre ovviamente NON possono fornire esattamente gli stessi risultati sul piano prestazionale. Che poi è il motivo del contendere sulla tessellation.

    Per cui è normale che un gioco abbia prestazioni diverse su schede diverse: succede già con GPU della stessa famiglia, figuriamoci con quelle di aziende diverse! La tessellation non ha portato nulla di nuovo, se non l’n-esima occasione di scontri.

    Spero sia chiaro il concetto.

    @ares17:

    Gia, perchè a leggere quello che scrivi sembra quasi che la cultura debba essere basata su una realtà distorta.

    E la realtà “vera” quale sarebbe?

    Attento ad utilizzare il termine “lucro” al posto di “profitto”, generalmente il primo è termine peggiorativo del secondo.

    Non vado molto per il sottile. Il concetto è quello, che sia positiva o negativa l’accezione.

    Riguardo la condanna alla triade: vorresti negare che non sia stata condannata dal tribunale sportivo della figc per aver anche investito € nell’acquisto di sim? (ps la giustizia sportiva si è pronunciata, quella civile è in atto).

    Non nego che sia stata messa in scena una farsa e approntato un precesso sommario in 8 giorni da cui è uscita fuori una sentenza già scritta sulla base del nulla.

    Perché le prove dell’impianto accusatorio era fallace già prima, e col processo civile le tesi sono state via via demolite. Difatti Moggi è stato prosciolto da tutti i procedimenti, e ne rimane ancora in corso uno in cui sta difendeno.

    D’altra parte dalla “giustizia” sportiva non ci si poteva aspetta null’altro che mettere al palo il classico capro espiatorio…

    Comunque preferirei tornare a parlare del solo argomento dell’articolo, visto che su questo s’è già scritto di tutto e di più.

    La ftc con quell’accordo ha imposto ad Intel un comportamento commerciale da tenere in futuro, non certo abbuonato eventuali illegalità che sono in corso di indagini (e la differenza è notevole), oltretutto tale accordo non mette al riparo Intel da eventuali ripercussioni legali in paesi extra-USA (vedo che continui a distorcere la realtà in modo da “acculturare” il consumatore che legge quello che scrivi alla tua personalissima visione delle cose)

    Mai detto nulla su questo e, anzi, sono per l’applicazione di pesantissime sanzioni per le pratiche di concorrenza sleale.

    Riguardo al compilatore Intel da diverso tempo sotto osservazione dell’antitrust vedo che hai le idee chiare:
    L’impossibilità di dimostrare che il codice prodotto svantaggi volutamente i concorrenti fa si che (per la presunta innocenza dovuta a tutti) si consideri il codice super ottimizzato per le cpu Intel invece che pessimizzato per i concorrenti.
    Tutto questo è valido fintanto che non venga dimostrato il contrario (E da Intel non si può pretendere certo che spenda tempo nello sviluppo di un compilatore ottimizzato per le cpu dei concorrenti).

    Mi sembra anche normale. Io, al posto di Intel, farei lo stesso. Non vedo perché dovrei favorire i concorrenti sviluppando ottimizzazioni per altre architetture oltre la mia.

    Per gli altri offro un code-path standard. Per le MIE, specifiche (perché si tratta di code path specifici, cosa che nessuno sottolinea), investo i MIEI soldi.

    Ps sono Juventino e nei miei case ho indifferentemente, a seconda dei prodotti disponibili in fase di acquisto, Intel, AMD, Nvidia, Via, Sis, ecc. Quindi cos’hai nel case non ti rende obiettivo ai miei occhi nelle tue esternazioni allo stesso modo che quello che ho io nei case non mi fa passare per obiettivo ai tuoi occhi (quello che ho scritto prima mi sembrava abbastanza chiaro, ma sei riuscito ugualmente a travisare.

    Veramente chi è partito in quarta dandomi del fanboy sei stato tu.

    Le mie valutazioni prescindono dalle marche in oggetto, e a situazioni invertite il mio giudizio non sarebbe cambiato di una virgola.

    Attento però, moralità e lucro nello stesso discorso difficilmente vanno a braccetto)

    Ne sono cosciente. Difatti il titolo dell’articolo è casuale…

  • # 17
    ares17
     scrive: 

    @cesare
    E la realtà “vera” quale sarebbe?
    @
    Che ubisoft usa una tecnica di tassellation inutile ai fini pratici, è come eseguire operazioni con precisione su 20 decimali e poi arrotondare il risultato solo al primo.

    @cesare
    Mi sembra anche normale. Io, al posto di Intel, farei lo stesso. Non vedo perché dovrei favorire i concorrenti sviluppando ottimizzazioni per altre architetture oltre la mia.

    Per gli altri offro un code-path standard. Per le MIE, specifiche (perché si tratta di code path specifici, cosa che nessuno sottolinea), investo i MIEI soldi.
    @

    Qui ti sbagli, i cosidetti code path specifici di intel sono applicabili anche ai Via (dimostrato in laboratorio dove grazie alla possibilità di modificare la id delle cpu Via si fa credere alle routine di avere a che fare con Genuine Intel), quindi andrei cauto nel sott’intendere che non possano essere applicati ad altre cpu, ma sempre grazie alla presunta buona fede di intel questo non è reato (fino a quando qualcuno all’interno di intel non dimostri il contrario).

    @cesare
    Veramente chi è partito in quarta dandomi del fanboy sei stato tu.
    @

    Questa è la versione corretta gentilmente da Marco:
    Se si *venisse* a scoprire che quello che è accaduto non *è* dovuto all’incapacità dei programmatori di ubisoft di sfruttare al meglio l’hardware disponibile sul mercato ma ad una precisa intenzione di favorire un approcio architetturale a sfavore di un’altro (concettualmente quasi agli antipodi) *rischieresti* di essere marchiato a vita come Fanboy.

    Come vedi non ho mai affermato che tu sia un fanboy, ma solo che al verificarsi di una condizione tu lo possa essere additato, che è ben diverso da quello che hai inteso.

    Che poi la possibilità di implementare una tecnica di tasselation come quella proposta nel bench ad un gioco che non ne infici la giocabilità stessa è tutta da dimostrare.

  • # 18
    Cesare Di Mauro (Autore del post)
     scrive: 

    @ares17:

    Che ubisoft usa una tecnica di tassellation inutile ai fini pratici, è come eseguire operazioni con precisione su 20 decimali e poi arrotondare il risultato solo al primo.

    Questo non è sempre detto, dipende sempre dal contesto. Un grado di tessellation elevato può essere utile quando l’area in cui applicarlo è più grande (ad esempio ci si trova più vicini).

    Il difetto della soluzione Ubisoft è che viene applicato sempre un livello elevato, anziché adottare tecniche di tessellation adattive (che è la strada gradita ad AMD).

    Una soluzione comoda, insomma, che non richiede molti sforzi.

    Qui ti sbagli, i cosidetti code path specifici di intel sono applicabili anche ai Via (dimostrato in laboratorio dove grazie alla possibilità di modificare la id delle cpu Via si fa credere alle routine di avere a che fare con Genuine Intel), quindi andrei cauto nel sott’intendere che non possano essere applicati ad altre cpu, ma sempre grazie alla presunta buona fede di intel questo non è reato (fino a quando qualcuno all’interno di intel non dimostri il contrario).

    Non mi sembra di aver scritto né lasciato intendere che non fossero applicabili ad architetture diverse da quelle di case Intel. Tra l’altro è cosa nota già da parecchio tempo: http://www.hwupgrade.it/news/cpu/boost-prestazionale-per-athlon-64-con-compilatore-intel_11677.html

    Ma abilitare un qualunque path non è sempre conveniente né comporta automaticamente la scelta della migliore ottimizzazione possibile, perché questo lo si fa sulla base della specifica architettura, come dicevo prima.

    Se leggi il manuale di Intel per le ottimizzazioni (che trovi qui http://www.intel.com/Assets/PDF/manual/248966.pdf ) te ne renderai conto da solo, ma per fare un esempio, generare codice ottimizzato per Pentium 4 / NetBurst, Core 2 Due / Nehalem e Atom richiede delle mirate e precise (a volte molto diverse) ottimizzazioni.

    Il compilatore di Intel può generare più code-path in base alle sue specifiche architetture, e a runtime può selezionare quello che “calza meglio”, ma questo lo può fare soltanto dopo aver verificato che si tratta effettivamente di una sua CPU, e andando poi a prelevare altri dati per vedere meglio di quale architettura si tratta.

    La stessa cosa non è applicabile a CPU di altre marche, perché le architetture sono diverse e richiedono ottimizzazioni diverse (vedi apposito manuale di AMD http://support.amd.com/us/Processor_TechDocs/40546-PUB-Optguide_3-11_5-21-09.pdf per esempio). Per cui bisognerebbe generare code-path appositi, e a runtime scegliere quello giusto.

    Ma a parte questo discorso squisitamente tecnico (che spero abbia chiarito la situazione), rimane quello di convenienza: anche se non fossi in buona fede, e quindi pienamente cosciente di non aver abilitato delle ottimizzazioni possibili per le altre CPU, non vedo cosa ci sia di male. Penso di avere tutto il diritto di investire i MIEI SOLDI per favorire le mie CPU. D’altra parte nessuno è obbligato a usare i MIEI compilatore, e i concorrenti possono benissimo investire nello sviluppo di compilatori che ottimizzino per le loro ISA; ma coi LORO soldi.

    Come vedi non ho mai affermato che tu sia un fanboy, ma solo che al verificarsi di una condizione tu lo possa essere additato, che è ben diverso da quello che hai inteso.

    Avevo inteso bene, e m’ero messo nel caso peggiore. E in questo caso continuo a ribadire: su quale base mi si potrebbe accusare di partigianeria?

    Che poi la possibilità di implementare una tecnica di tasselation come quella proposta nel bench ad un gioco che non ne infici la giocabilità stessa è tutta da dimostrare.

    Anche qui, mai sostenuto questa tesi. Non capisco perché tu debba mettermi in bocca parole che non mi sono mai sognato di scrivere né di pensare.

    Anzi, è chiaro che la giocabilità ne può risultare compromessa, visto che le prestazioni sulle schede video AMD subiscono un brusco scalo. Se così non fosse non ci sarebbero nemmeno state le basi per scrivere quest’articolo.

    Ma il calo delle prestazioni ce l’hai anche se utilizzi schede video Nvidia di fascia bassa. Non è un problema legato esclusivamente alla tessellation, come ho già detto. E’ normale che le prestazioni varino in base al sistema su cui gira il gioco in questione.

    Sulle GPU AMD questo è più evidente sulla scorta dell’ATTUALE implementazione del tessellator.

    Ma se un domani AMD correggesse questo problema o tramite driver o con una prossima revisione della GPU, implementandone uno comparabile (magari superiore!) a quello di Nvidia, cos’avreste da dire?

  • # 19
    j
     scrive: 

    @ares17
    a quanto scritto da cesare aggiungerei due cose:
    da una parte tieni presente che la sequenza di istruzioni ottimale per un processore dipende già dalle sue caratteristiche architetturali, qualitative E quantitative – ovvero da un gran numero di fattori varianti tra famiglie diverse di chip
    ma anche dagli eventuali errata, intrinsecamente peculiari della specifica famiglia ma anche della specifica revisione, giacchè alcuni (ma non tutti, non sempre) gli errata presenti in una revision possono essere risolti in quella successiva, e non richiedere l’ eventuale workaround tipicamente costituito da sequenze di istruzioni ad hoc

    ora, va da sè che se tu sei un produttore di chip che produce un compilatore come accessorio per i propri processori (*) e non è in effetti tenuto a conoscere peculiarità e difetti di quelli della concorrenza, avrai già abbastanza da fare per implementare in esso ottimizzazioni, workaround e quirks tenendo conto appunto delle caratteristiche e dei difetti dei tuoi (che conoscerai, avendoli progettati tu), e ottimizzare in funzione di quelli altrui sia al di là del tuo scope …

    * d’ altra parte una cosa che mi chiedo spesso è: perchè AMD e Via non producono a loro volta dei compilatori ottimizzanti per i propri processori, e non cercano di diffonderne l’ uso tra gli sviluppatori (cioè, perchè non seguono l’ esempio di intel)?
    in realtà la domanda è retorica, non lo fanno perchè non ne hanno le risorse e il peso – e perchè il compilatore intel esiste da tanto tempo, ed è tanto diffuso (quindi è in circolazione da tanto tempo, così tanto sw compilato con esso) che a questo punto non farebbe differenza (oltre ad essere irrealistico)

    quindi AMD e Via operano in modo diverso (e non da ieri, come minimo dall’ epoca dei 6×86 vs Pentium se si considerano altri vendor come Cyrix) progettando architetture capaci (almeno sulla carta) di prestazioni adeguate anche con codice generico, laddove intel può permettersi di progettare architetture accomunate dall’ essere magari performanti ma a tratti sbilanciate (ivi compreso il Core i7, il cui decoder non è simmetrico come quello del via nano e degli amd K8/k10) contando sul fatto che in effetti il prodotto sia costituito dall’ abbinamento di CPU e compilatore, e non dal solo chip – come per i primi

    quindi il fatto che

    i cosidetti code path specifici di intel sono applicabili anche ai Via

    è in effetti coincidentale, e che

    grazie alla presunta buona fede di intel questo non è reato

    , vorrei capire in base a quale principio vendere una “suite” composta da chip E compilatore ottimizzante per quei chip, possa diventare un reato…

  • # 20
    Ares17
     scrive: 

    @Cesare
    Anche qui, mai sostenuto questa tesi. Non capisco perché tu debba mettermi in bocca parole che non mi sono mai sognato di scrivere né di pensare.
    @
    Non ti ho messo in bocca questo, semplicemente era un’osservazione poichè credo che quella tecnica di tassellazione porti dei cicli di utilizzo processore maggiore che una adattiva, ed quando in game la cpu deve gestire anche altre funzioni (IA, fisica, audio 3d ed altre cose) il collo di bottiglia si sposterebbe altrove.

    @J
    a quanto scritto da cesare aggiungerei due cose:
    da una parte tieni presente che la sequenza di istruzioni ottimale per un processore dipende già dalle sue caratteristiche architetturali, qualitative E quantitative – ovvero da un gran numero di fattori varianti tra famiglie diverse di chip
    @
    Verissimo, ma stiamo parlando di ottimizzazioni:
    Far eseguire istruzioni in sse2 al 100% delle possibilità dell’architettura è un bene, ma se vengono adottati path che non sono ottimizzati potrebbero far crollare le prestazioni al 20% delle reali capacità di calcolo, ma sempre meglio che far eseguire la stessa operazione in x86 generico (che nel migliore dei casi avrebbe un indice prestazionale nell’ordine di 1/20 rispetto alle sse2.
    Ma queste sono solo supposizioni difficilmente dimostrabili (ed intel non dimostrerà mai il contrario).

    @J
    vorrei capire in base a quale principio vendere una “suite” composta da chip E compilatore ottimizzante per quei chip, possa diventare un reato
    @

    Con lo stesso principio che l’antitrust europeo ha multato MS per l’affare browser e per lo stesso principio per il quale Intel stessa è sotto inchiesta per l’affare sconti (ai tempi dei P4 vs Athlon Intel aveva paventato la possibilità di non poter garantire ad acer la fornitura costante di cpu nel caso quest’ultima avesse aumentato le linee notebook con cpu AMD, secondo voci confidenziali interne ad acer).

    Purtroppo (o per fortuna) l’economia è basata su leggi relative (cio che è perfettamente legale oggi potrebbe non esserlo domani) e sono sicuro che se Amd rischiasse il fallimento il primo a muoversi per salvarla sarebbe proprio Intel (come fece a suo tempo MS con Apple comprando azioni di quest’ultima con lo scopo ben preciso di dare fiducia agli investitori e conseguente boccata d’ossigeno per il marchio).

  • # 21
    Cesare Di Mauro (Autore del post)
     scrive: 

    @Ares17:

    Non ti ho messo in bocca questo, semplicemente era un’osservazione poichè credo che quella tecnica di tassellazione porti dei cicli di utilizzo processore maggiore che una adattiva, ed quando in game la cpu deve gestire anche altre funzioni (IA, fisica, audio 3d ed altre cose) il collo di bottiglia si sposterebbe altrove.

    Questo è pacifico e l’avevo già detto: hanno semplicemente applicato la tessellation nella maniera più comoda possibile, con tutte le implicazioni del caso.

    Questo comporta un calo prestazionale nelle ATTUALI architetture di AMD, perché quest’ultima ha implementato il tessellator in maniera diversa da Nvidia. E’ una scelta che al momento lei paga cara.

    Se avesse adottato una soluzione simile o migliore di Nvidia (cosa possibilissima), staremmo ancora qui a parlarne? Perché non l’ha fatto? Già con la precedente generazione di schede video 5×00 era noto che il suo tessellator avesse dei pesanti limiti, e anche se con le recenti 6×00 la situazione è migliorata, siamo ancora ben lontani da quanto offerto da Nvidia.

    Questo su una funzionalità cardine delle DirectX 11, sulla quale lei stessa ha basato la sua campagna di marketing per aggredire un mercato in cui Nvidia era assente (e lo è stato per mesi), riuscendo a guadagnare significative quote e ritornando, a mio avviso, ai fasti di R300 e delle Radeon 9800.

    Con l’introduzione di Fermi le cose (sostanzialmente ad aprile) sono cambiate, ma ciò nonostante avrebbe avuto tutto il tempo per metter mano alla sezione di tessellation. Non l’ha fatto e continua a pagarne le conseguenze.

    E ribadisco: se domani offrisse una soluzione software allo scopo, oppure una revisione della GPU con un tessellator all’altezza della concorrenza, staremmo ancora qui a parlarne?

    Non capisco perché nei commenti nessuno ha fatto considerazioni di questo tipo, né tanto meno abbia risposto a queste precise domande che ho posto…

    Verissimo, ma stiamo parlando di ottimizzazioni:
    Far eseguire istruzioni in sse2 al 100% delle possibilità dell’architettura è un bene, ma se vengono adottati path che non sono ottimizzati potrebbero far crollare le prestazioni al 20% delle reali capacità di calcolo, ma sempre meglio che far eseguire la stessa operazione in x86 generico (che nel migliore dei casi avrebbe un indice prestazionale nell’ordine di 1/20 rispetto alle sse2.
    Ma queste sono solo supposizioni difficilmente dimostrabili (ed intel non dimostrerà mai il contrario).

    Forse non ti è chiaro il fatto che le implementazioni delle unità SIMD sono esse stesse diverse e richiedono ottimizzazioni diverse e specifiche. Secondo te quella di un P4/NetBurst, di un Core Duo 2 / Nehalem, e di un Atom sono identiche? Si ottimizzano allo stesso modo? Se ti vai a vedere le specifiche nel manuale delle ottimizzazioni, come ti avevo detto nel precedente commento, vedrai che hanno caratteristiche peculiari che richiedono apposite ottimizzazioni per essere sfruttate al meglio.

    Il compilatore Intel può generare code path diversi per le SSE, a seconda della specifica architettura.

    Secondo te quale code path dovrebbe scegliere per architetture diverse dalle proprie? Uno a caso immagino, e magari venire accusata ancora una volta di sabotare la concorrenza perché avrebbe potuto sceglierne un altro giudicato “migliore”.

    Intel con architetture diverse dalle proprie NON ha elementi per scegliere un code path piuttosto che un altro, e preferisce optare per quello generico. Scelta condivisibile o meno, ma ha un preciso perché sia dal punto di vista tecnico che di mera convenienza. Ma sicuramente è una scelta legittima.

    Con lo stesso principio che l’antitrust europeo ha multato MS per l’affare browser e per lo stesso principio per il quale Intel stessa è sotto inchiesta per l’affare sconti (ai tempi dei P4 vs Athlon Intel aveva paventato la possibilità di non poter garantire ad acer la fornitura costante di cpu nel caso quest’ultima avesse aumentato le linee notebook con cpu AMD, secondo voci confidenziali interne ad acer).

    Sono due cose che non c’entrano assolutamente nulla. Intel NON opera in regime di monopolio né di posizione dominante nel campo dei compilatori, anche perché i suoi se li fa pagare molto cari e se li possono permettere in pochi.

    Inoltre l’antitrust americano ha stabilito che il suo modus operandi è perfettamente legittimo nella misura in cui gli acquirenti vengano semplicemente informati che il codice generato non è ottimizzato per architetture diverse dalla propria.

    Risoluzione apprezzabile, e d’altra parte l’unica realmente sensata, considerato che si tratta di un suo prodotto, e che i soldini per la ricerca e lo sviluppo per generare codice ottimizzato li caccia fuori lei, e ha interesse a farlo soltanto per le sue CPU.

    D’altra parte ancora una volta vedo che mancano risposte a domande scomode: perché la concorrenza non sviluppa compilatori ottimizzati per le proprie architetture? Se non hanno sufficienti risorse, perché non aiutano compilatori esistenti? In questo modo risolverebbero i loro problemi, no?

    P.S. Mi scuso per gli errori presenti nei precedenti commenti, ma ero “cotto”, come si suol dire.

  • # 22
    ares17
     scrive: 

    @Cesare
    Sono due cose che non c’entrano assolutamente nulla. Intel NON opera in regime di monopolio né di posizione dominante nel campo dei compilatori, anche perché i suoi se li fa pagare molto cari e se li possono permettere in pochi.
    @
    Intel ha il 90% del mercato cpu (come ms lo ha nel mercato Os, e che sia il compilatore o il browser non detengono nemmeno l’80% dello share).

    Questo fa si che il compilatore possa attirare l’attenzione dell’antitrust, ma non è allo stesso tempo un illecito.

    Con la scusa che non possono identificare il code path migliore (che poi GCC come fa?) vengono utilizzati code path x86 generiche (che sono di molto più lente dal lato esecuzione).

    @cesare
    D’altra parte ancora una volta vedo che mancano risposte a domande scomode: perché la concorrenza non sviluppa compilatori ottimizzati per le proprie architetture? Se non hanno sufficienti risorse, perché non aiutano compilatori esistenti? In questo modo risolverebbero i loro problemi, no?
    @

    Perchè tu acquisteresti un compilatore AMD e dover compilare 2 volte (ma anche 3, o 4) per avere un aumento delle prestazione nell’ordine del 5-10% per famiglie di cpu che coprono il 15% massimo del totale?

    C’è da dire comunque che il compilatore Intel raggiunge ottime prestazioni e probabilmente non è secondo nemmeno a GCC su codice non ottimizzato.

    Continui ad auspicare che AMD abbandoni il suo approcio al Tasselation in favore di quello Nvidia, ma ometti di dire però che le unità di calcolo in Nvidia sono condivise, e che in nessun gioco fin’ora si sono viste implementazioni massicce di tassellation (nemmeno paragonabili a quelle dei bench) e che la presunta superiorità dell’approcio Nvidia non è dimostrata nelle applicazioni reale (dove le stesse unità di calcolo devono gestire molte più cose in concorrenza le une con le altre) quindi prima di arrivare a conclusioni definitive preferirei aspettare applicazioni che davvero sfruttino la tecnica, e non solo i bench (spesso dispositivi dalle prestazioni teoriche elevate in realtà si sono dimostrate nell’utilizzo reale avere prestazioni nella media se non inferiori).
    I bench sono in fin dei conti delle demo tecnologiche con un contatore di frame e possono enfatizzare determinati comportamenti, ma anche distorcere i reali valori i campo (come con la 2900xt che aveva un punteggio superiore alla 8800gtx nel 3d mark, ma che nel reale era spesso inferiore anche alla 8800 gts)

  • # 23
    j
     scrive: 

    Verissimo, ma stiamo parlando di ottimizzazioni:

    no, stiamo (almeno io sto) parlando di questa roba qua
    http://www.geek.com/images/geeknews/2006Jan/core_duo_errata__2006_01_21__full.gif (ad esempio per gli errata dei C2D – di cui anche quelli segnati in verde richiedono workaround nella forma di code path ad hoc rispetto ad altre famiglie (che magari non soffriranno di quegli errata ma possibilmente ne avranno di diversi) e ad altre revisioni (che potranno soffire degli stessi errata o magari di meno – se vengono fixati tra revisioni successive, ma nel caso specifico pare che di solo uno degli errata del C2D fosse previsto il fix) di chip

    Con la scusa che non possono identificare il code path migliore […] vengono utilizzati code path x86 generici

    non lo possono identificare perchè vorrebbe dire, a monte, stare dietro alle evoluzioni delle famiglie di chip concorrenti, foreach stepping – oltre che dei propri – ma a parte la replicazione del lavoro e dell’ impegno di sviluppo, che ne consegue (e che i concorrenti di certo non sovvenzionano) gli internals delle cpu altrui, intel non dovrebbe nemmeno conoscerli…

    certo si può rispondere che il via nano ha migliori prestazioni facendo in modo che sia riconosciuto come un core2
    ma allora, perchè via non chiede a intel di supportare il nano nello stesso code path usato per il core2 (o quel che è)?
    un problema è che così facendo dimostrerebbe di aver fatto reverse engineering del compilatore per capire a quale cpu intel corrisponde il code path (che prevederà workaround, quirks e quant’ altro, oltre alle ottimizzazioni, per quella cpu – per quello dicevo che il fatto che il via nano vi giri, sia coincidentale) che più si attaglia alla sua
    anche per questo, usare un code path generico per tutto ciò che non è “GenuineIntel” (e per le famiglie GenuineIntel più vecchie), è l’ opzione più logica per entrambe le parti – e l’ unica cosa davvero sensata per i concorrenti, chiedere che venga affinato il code path generico

    (che poi GCC come fa?)

    GCC semplice, non lo fa
    da http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Options.html :

    Applications which perform runtime CPU detection must compile separate files for each supported architecture, using the appropriate flags. In particular, the file containing the CPU detection code should be compiled without these options.

    cioè, gli sviluppatori di un’ applicazione in cui si debbano prevedere code path separati per più processori differenti, devono fare tutto a mano, 1) compilando un file oggetto (nota, non ho detto eseguibile) che conterrà la versione specificamente ottimizzata del codice, per ciascuno, e un file a parte (compilato come generico), contenente la parte di codice (che andrà scritto (*)) che in base al tipo di cpu sceglierà quale usare – ma trattandosi di file oggetto separati, l’ interfacciamento con il primo avverrà attraverso API come per una libreria;
    quindi 2) compartimentando codice neutro e codice ottimizzabile/differenziabile in sede di progetto, e inserendo controlli e chiamate esplicite in sede implementativa

    quindi se si volesse supportare cpu diverse (anche solo famiglie diverse di uno stesso produttore, quindi fare la stessa cosa di intel) sarebbe necessario un certo lavoro in più – che molti (progetti e distribuzioni linux) finiscono per non fare, preferendo fornire un’ unica versione binaria standard, tipicamente compilata per i686
    che in pratica è l’ “i386″ (cioè il baseline) del 2010 – anche se una scelta che sacrifica una parte consistente dell’ utenza, visto che, per dire, il pentium4 vi rende malissimo a causa della pipeline completamente diversa da quella di PPro/P2/P3…)

  • # 24
    Cesare Di Mauro (Autore del post)
     scrive: 

    @ares17:

    Intel ha il 90% del mercato cpu (come ms lo ha nel mercato Os, e che sia il compilatore o il browser non detengono nemmeno l’80% dello share).

    Questo fa si che il compilatore possa attirare l’attenzione dell’antitrust, ma non è allo stesso tempo un illecito.

    Sono due mercati diversi, seppur correlati. Una similitudine sarebbe potuta essere quella fra Windows e Office, ma Microsoft non è stata citata in giudizio per la sua suite. Questo perché il dominio nel mercato dei s.o. non equivale automaticamente a un dominio nel mercato delle suite da ufficio, in quanto queste ultime si acquistano separatamente.

    Come dire: non è che se compri una CPU intel, ti vendono pure il relativo compilatore, o ti obbligano a farlo. Ribadisco: sono due prodotti completamente diversi, che hanno mercati diversi.

    D’altra parte il fatto che Intel produca compilatori per i suoi processori, non significa che sia la migliore, e l’unica a cui rivolgersi. Infatti ha pure ottimi compilatori Fortran, ma in questo mercato ci sono aziende che vendono prodotti che generano codice mediamente migliore del suo.

    Con la scusa che non possono identificare il code path migliore (che poi GCC come fa?) vengono utilizzati code path x86 generiche (che sono di molto più lente dal lato esecuzione).

    Per GCC (e altro) ti ha risposto j, col quale concordo.

    Per il resto, non è possibile effettuare scelte su architetture della concorrenza, perché i dati dell’architettura estratti da istruzioni come CPUID hanno significati completamente diversi.

    Controlla tu stesso qui http://en.wikipedia.org/wiki/CPUID#EAX.3D1:_Processor_Info_and_Feature_Bits in primis, e poi nei manuali delle architetture dei singoli processori.

    Perchè tu acquisteresti un compilatore AMD e dover compilare 2 volte (ma anche 3, o 4) per avere un aumento delle prestazione nell’ordine del 5-10% per famiglie di cpu che coprono il 15% massimo del totale?

    E quindi? Anche se ci fosse non vorresti usarlo? Ti rendi conto di cosa stai affermando?

    Ma di cosa ti lamenti, allora, per il compilatore Intel? E’ incomprensibile.

    C’è da dire comunque che il compilatore Intel raggiunge ottime prestazioni e probabilmente non è secondo nemmeno a GCC su codice non ottimizzato.

    Ne ho parlato un po’ in un articolo: http://www.appuntidigitali.it/10525/gcc-il-miglior-compilatore-al-mondo/

    Continui ad auspicare che AMD abbandoni il suo approcio al Tasselation in favore di quello Nvidia, ma ometti di dire però che le unità di calcolo in Nvidia sono condivise, e che in nessun gioco fin’ora si sono viste implementazioni massicce di tassellation (nemmeno paragonabili a quelle dei bench)

    Ancora una volta, non ho detto questo, ma soltanto di potenziare l’unità di tessellation, o provvedere via software utilizzando i numerosi stream processor. Si tratta, insomma, di offrire una soluzione migliore dell’attuale (anche della concorrenza, eventualmente), qualuque sia l’implementazione scelta.

    Perché è una caratteristica di punta delle DirectX 11, e col tempo prenderà sempre più piede.

    e che la presunta superiorità dell’approcio Nvidia non è dimostrata nelle applicazioni reale (dove le stesse unità di calcolo devono gestire molte più cose in concorrenza le une con le altre) quindi prima di arrivare a conclusioni definitive preferirei aspettare applicazioni che davvero sfruttino la tecnica, e non solo i bench (spesso dispositivi dalle prestazioni teoriche elevate in realtà si sono dimostrate nell’utilizzo reale avere prestazioni nella media se non inferiori).

    Perdonami, ma se il benchmark in oggetto utilizza l’engine del gioco finale, l’applicazione sarà reale…

    I bench sono in fin dei conti delle demo tecnologiche con un contatore di frame e possono enfatizzare determinati comportamenti, ma anche distorcere i reali valori i campo (come con la 2900xt che aveva un punteggio superiore alla 8800gtx nel 3d mark, ma che nel reale era spesso inferiore anche alla 8800 gts)

    Non mi sono mai piaciuti i benchmark sintetici, ma preferisco sempre valutare NUMEROSE applicazioni reali. Quello in questione dovrebbe utilizzare l’engine di un gioco reale, per cui tanto “sintetico” non è, e… ha il suo peso.

    Ha il suo peso soprattutto nella guerra di marketing fra le due aziende rivali, come già detto.

  • # 25
    ares17
     scrive: 

    @J
    @Cesare
    Quindi secondo quando affermate tutti i programmi compilati per con sse4 in presenza di cpu non riconusciute (I7 SB e IB prossime uscite di Intel) utilizzeranno il code path sse2 invece sse4.2 girando per forza di cose più piano?
    O applicheranno un path sse4.2 generico senza ottimizzazioni per famiglia processori?

  • # 26
    Marcello Maggioni
     scrive: 

    Non sono d’accordo Cesare, per il semplice motivo che se ci sono due tecniche, una che va bene per entrambe le architetture (una tra l’altro anche migliore a livello tecnico e teorico, che sarebbe il modello adattativo) e una che invece va male su una e bene sull’altra non c’è ragione di scegliere la seconda se non per un solo motivo: i soldi.

    Vogliamo veramente finire in un mondo in cui AMD ed Nvidia si mettono a pagare le software houses per DISottimizzare i giochi per le piattaforme della rivale? Chi finisce per vincere veramente in questo scenario? Di certo non gli utenti finali che potranno giocare bene solo alla metà dei giochi non DISottimizzati per la propria architettura …

    Poi la tessellation implementata in HAWX 2 fa ridere, la differenza non si vede neanche attraverso gli screenshots … non hanno usato displacement mapping (o se l’hanno usato l’hanno usato pochissimo), quindi tessellare il terreno è stato completamente inutile … un’altra mossa di marketing tipica dello scenario che ho appena descritto e che spero non si verifichi mai completamente.

  • # 27
    mede
     scrive: 

    comunque il motivo per cui lo trovo sbagliato è principalmente il fatto che tutto questo non produce nulla di positivo. nel caso delle console, se proprio vogliamo, possiamo ravvisare una differenza di architettura hardware che se non altro produce una certa “hardwarediversità”, che alla lunga può addirittura a benefici per tutti nella ricerca di nuove soluzioni. ma nel caso delle schede video, di fatto questo non avviene. accetterei una mancanza di compatibilità a fronte di due soluzioni che vanno volutamente in due direzioni completamente diverse, proponendo due prodotti incompatibili con pro e contro, ma non ha senso in questo caso a mio avviso, non produrrà mai nulla di positivo per il mercato, solo a breve termine per chi fa la marchetta. per questo ritengo sia un comportamento che andrebbe censurato.

  • # 28
    Cesare Di Mauro (Autore del post)
     scrive: 

    Sbagli mede, perché non serviva di certo HAWX 2 per dimostrare una cosa già nota e che succede da anni: schede video di marche diverse hanno prestazioni diverse; addirittura capita anche fra schede della stessa marca.

    E gli sviluppatori ne tengono già conto quando scelgono quale parco hardware supportare, e come, per i loro giochi.

    Davvero, HAWX 2 non ha portato nulla di nuovo. Semplicemente si tratta dell’n-esimo caso.

    @ares17:

    Quindi secondo quando affermate tutti i programmi compilati per con sse4 in presenza di cpu non riconusciute (I7 SB e IB prossime uscite di Intel) utilizzeranno il code path sse2 invece sse4.2 girando per forza di cose più piano?
    O applicheranno un path sse4.2 generico senza ottimizzazioni per famiglia processori?

    Non conosco i dettagli del dispatcher, ma credo che le ottimizzazioni funzioni per “famiglie” di processori. Ad esempio un codice ottimizzato per un Atono 250 sarà fatto funzionare anche su un Atom 450 o 550, anche se queste CPU non erano ancora state commercializzate.

    @Marcello Maggioni:

    Non sono d’accordo Cesare, per il semplice motivo che se ci sono due tecniche, una che va bene per entrambe le architetture (una tra l’altro anche migliore a livello tecnico e teorico, che sarebbe il modello adattativo) e una che invece va male su una e bene sull’altra non c’è ragione di scegliere la seconda se non per un solo motivo: i soldi.

    Questo l’ho detto chiaramente anche nell’articolo.

    Vogliamo veramente finire in un mondo in cui AMD ed Nvidia si mettono a pagare le software houses per DISottimizzare i giochi per le piattaforme della rivale? Chi finisce per vincere veramente in questo scenario? Di certo non gli utenti finali che potranno giocare bene solo alla metà dei giochi non DISottimizzati per la propria architettura …

    Non è certamente un bello scenario, ma parlerei più che altro di mancanza di ottimizzazione anziché di disottimizzazione. Il primo caso è lecito, il secondo si configura come concorrenza sleale ed è punito dalla legge.

    Poi la tessellation implementata in HAWX 2 fa ridere, la differenza non si vede neanche attraverso gli screenshots … non hanno usato displacement mapping (o se l’hanno usato l’hanno usato pochissimo), quindi tessellare il terreno è stato completamente inutile … un’altra mossa di marketing tipica dello scenario che ho appena descritto e che spero non si verifichi mai completamente.

    Concordo, e l’ho anche scritto nell’articolo. ;)

Scrivi un commento!

Aggiungi il commento, oppure trackback dal tuo sito.

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.