Roma – Il giudice della corte distrettuale del Texas ha confermato la decisione secondo cui Apple violerebbe il brevetto ‘ 291 in possesso di OPTi, e l’ha condannata a pagare 21,7 milioni di dollari (19 di risarcimento e 2,7 di interessi) all’azienda detentrice della privativa sulla memoria cache. Chiudendo così, momentaneamente, un caso aperto nel gennaio 2007.
La OPTi dal 2003 ha cessato le sue attività produttive e commerciali per concentrarsi sulle cause legali: è andata in tribunale anche con AMD e si è già aggiudicata 10 milioni di dollari da NVIDIA (da cui ha ottenuto anche un buon accordo di licenza) e 650 mila dollari dalla produttrice di chip taiwanese Via . Tutti questi casi riguardato argomenti simili, e nel caso Apple ad essere portato all’attenzione del giudice è il brevetto dal titolo Predictive Snooping of Cache Memory for Master-Initiated Accesses ottenuto su una tecnologia per la gestione della memoria cache nel sistema operativo.
La difesa di Cupertino aveva tentanto di dimostrare che il brevetto era di per sé invalido perché non innovativo, ovvio cioè rispetto allo stato dell’arte. Tali argomentazioni sono state respinte dal giudice, che ha però riconosciuto a Apple l’attenuante della non volontarietà. Contro la sua decisione, tuttavia, Cupertino ha già dichiarato di voler ricorrere in appello.
Non è l’unico problema legale della Mela, costretta ora a difendersi anche dall’accusa di St. Clair Intellectual Propert Consultants (società costituita da due avvocati) per cui la fotocamera di iPhone violerebbe quattro suoi brevetti. Il caso è stato denunciato alla corte distrettuale del Delaware. Con le stesse tecnologie la società ha già vinto contro Sony e Canon, aggiudicandosi quasi 60 milioni di dollari in danni. Mentre la maggior parte degli altri soggetti portati in tribunale, praticamente tutti i maggiori produttori di fotocamere nel mondo, hanno deciso di siglare un accordo di licenza.
Claudio Tamburrino
leggi i 22 commenti
-
A conferma
a conferma dei dubbi sollevati alla presentazione del progetto.Implementare via software (tra l'altro in un'architettura non specializzata come x86) porta maggiore flessibilita', ma anche prestazioni piu' scadenti, e nell'ambito delle schede video, dove le prestazioni sono tutto, la storia era gia' scritta...-
Re: A conferma
la questione però è più complessaoggi i motori grafici usano directx o opengl per le loro necessità e quindi sono costretti ad operare entro un determinato recinto sia come funzionalità supportate che come implementazioneovviamente potendo creare un motore grafico software vuol dire che puoi usare delle scorciatoie, compattare il codice, renderlo più veloce in termini di numero di operazioni rispetto alla controparte hardware e ottenere così risultati migliori dell'hardwarequesto però sempre che sotto ci sia un hardware adeguato e realisticamente gli x86 non sono quella che si può definire un'architettura flessibile, moderna e leggeragli arm lo dimostrano riuscendo ad erogare le stesse performance ad una frazione del costo in termini di silicio e di corrente consumatasecondo me intel se proprio vuole provarci deve usare un'architettura nuova oppure giocare la carta degli fpga, cosa che per loro non dovrebbe essere troppo difficile, anche se attualmente ati e nvidia ci arriverebbero molto prima-
Re: A conferma
oggi i motori grafici usano directx o opengl per
le loro necessità e quindi sono costretti ad
operare entro un determinato recinto sia come
funzionalità supportate che come
implementazioneI motori grafici si appoggiano a directx o a opengl per una infinita' di motivi, primo fra tutti la compatibilita'. Non vedo inoltre come tali librerie possano essere viste come un "recinto", dato che supportano tutte le chiamate grafiche necessarie, e te lo garantisce uno che ha programmato in opengl 17 anni fa ...Se proprio vuoi uscire dal recinto, esiste CUDA. L'architettura x86 e' obsoleta da almeno un decennio, ma siamo costretti a contiunare ad usarla (principalmente per colpa di M$).-
Re: A conferma
se hai usato cuda, avrai notato però che mancano molte cose....la flessibilità del modello a kernel non è lontanamente paragonabile a quella del modello di programmazione delle cpualtro problema è la possibilità di avere un modello di memoria coerente, non essere sbatacchiato tra ram video e ram di sistema continuamentealtro problema è la possibilità di avere un supporto al c++ e agli oggetti....cuda usa il c fondamentalmentecuda usa la gpu e gli stream proXXXXXr e quindi è limitato ad operare su matrici, vettori, a far conti in sostanza...manca la flessibilità necessaria per manipolare efficacemente stringhe, supportare il branchinge poi perchè no, bisogna ragionare in parallelo con le gpu e tenendo conto che i programmatori odiano ragionare in termini di multithread, multiprocessi, ecc... non è uno svantaggio da pocodel resto se le gpu fossero general purpose verrebbero usate al posto delle cpu-
Re: A conferma
- Scritto da: pabloski
se hai usato cuda, avrai notato però che mancano
molte cose....la flessibilità del modello a
kernel non è lontanamente paragonabile a quella
del modello di programmazione delle
cpu?!?!?!?!?!?
altro problema è la possibilità di avere un
modello di memoria coerente, non essere
sbatacchiato tra ram video e ram di sistema
continuamenteAttualmente in fase di programmazione tu te ne sbatti della memoria video e della memoria di sistema, in quanto sono i driver a gestire la memoria in base alle chiamate alle varie api.Operando direttamente sull'hw è diverso; CUDA e Stream ti permettono di programmare direttamente sulla GPU e di conseguenza vedi unicamente le risorse GPU.
altro problema è la possibilità di avere un
supporto al c++ e agli oggetti....cuda usa il c
fondamentalmenteNon ti sta bene che CUDA sia modellato sul C? diventa presidente di Nvidia e cambia le cose; comunque vi sono binding per un fot*io di linguaggi.
cuda usa la gpu e gli stream proXXXXXr e quindi è
limitato ad operare su matrici, vettori, a far
conti in sostanza...manca la flessibilità
necessaria per manipolare efficacemente stringhe,
supportare il
branchingSo it shall be written so it shall be doneTradotto se un auto viene progettata per essere un mezzo di trasporto terrestre è assurdo volerla usare come supposta.
e poi perchè no, bisogna ragionare in parallelo
con le gpu e tenendo conto che i programmatori
odiano ragionare in termini di multithread,
multiprocessi, ecc... non è uno svantaggio da
pocoed è per questo che cuda o chi per esso ha delle funzioni per gestire agilmente i thread senza andare con fork(); if (pid==0){..}else{..} ...
del resto se le gpu fossero general purpose
verrebbero usate al posto delle
cpuFermo ... inverti .. Bravo, ora sai cosa vuole fare intel, più o meno il contrario di quello che eri convinto. -
Re: A conferma
- Scritto da: Vault Dweller
- Scritto da: pabloski
se hai usato cuda, avrai notato però che mancano
molte cose....la flessibilità del modello a
kernel non è lontanamente paragonabile a quella
del modello di programmazione delle
cpu
?!?!?!?!?!?
è lunga da spiegare, leggiti la documentazione di cuda
Attualmente in fase di programmazione tu te ne
sbatti della memoria video e della memoria di
sistema, in quanto sono i driver a gestire la
memoria in base alle chiamate alle varie
api.ah si? e la necessità di copiare da e verso la memoria video tutti i dati da elaborare? a volte si parla di matrici di enormi dimensioni
Operando direttamente sull'hw è diverso; CUDA e
Stream ti permettono di programmare direttamente
sulla GPU e di conseguenza vedi unicamente le
risorse
GPU.
no il software gira sulla cpu e invia kernels e dati alla gpupuoi allocare degli oggetti dati in memoria video e usare i kernel per manipolarli
Non ti sta bene che CUDA sia modellato sul C?
diventa presidente di Nvidia e cambia le cose;
comunque vi sono binding per un fot*io di
linguaggi.
che risposta è inutile....i binding servono per interfacciarsi a cuda non per scrivere i kernel da eseguire sulla gpu
So it shall be written so it shall be done
Tradotto se un auto viene progettata per essere
un mezzo di trasporto terrestre è assurdo volerla
usare come
supposta.
appunto, quindi larrabee un senso ce l'ha
ed è per questo che cuda o chi per esso ha delle
funzioni per gestire agilmente i thread senza
andare con fork(); if (pid==0){..}else{..}
...
ci sono pure sistemi operativi che gestiscono i thread, il fork riguardo il multiprocessing non il multithreading, sono due cose completamente differenti
Fermo ... inverti .. Bravo, ora sai cosa vuole
fare intel, più o meno il contrario di quello che
eri
convinto.ecco, finiscila di dire XXXXXXX -
Re: A conferma
- Scritto da: pabloski
- Scritto da: Vault Dweller
- Scritto da: pabloski
se hai usato cuda, avrai notato però che
mancano
molte cose....la flessibilità del modello a
kernel non è lontanamente paragonabile a
quella
del modello di programmazione delle
cpu
?!?!?!?!?!?
è lunga da spiegare, leggiti la documentazione di
cuda
Attualmente in fase di programmazione tu te ne
sbatti della memoria video e della memoria di
sistema, in quanto sono i driver a gestire la
memoria in base alle chiamate alle varie
api.
ah si? e la necessità di copiare da e verso la
memoria video tutti i dati da elaborare? a volte
si parla di matrici di enormi
dimensioniScusa l'incomprensione ma visto che avevi risposto ad un commento che parlava di opengl &co ho creduto che ti colleggassi ad esso. Comunque è assolutamente logico, in quanto per varie questioni, tra cui la sicurezza e l'integrità dei dati le GPU non possono accedere autonomamente ai dati nella memoria di sistema; le GPU sono come ogni altro componente asservite alla CPU, non a caso essa si chaima così anziche Superflous Processing Unit.
Operando direttamente sull'hw è diverso; CUDA e
Stream ti permettono di programmare direttamente
sulla GPU e di conseguenza vedi unicamente le
risorse
GPU.
no il software gira sulla cpu e invia kernels e
dati alla
gpu
puoi allocare degli oggetti dati in memoria video
e usare i kernel per
manipolarliKernel = modulo CUDASoftware : vede interfaccia CUDACiò implica che se tu scrivi in CUDA scrivi codice per la GPU, che richiami in software ttramite l'interfaccia driver di cuda.
So it shall be written so it shall be done
Tradotto se un auto viene progettata per essere
un mezzo di trasporto terrestre è assurdo
volerla
usare come
supposta.
appunto, quindi larrabee un senso ce l'haNo perché se è solo la divisone della memoria che tu lamenti essa esisterebbe anche con larrabee, in quanto essa non sostituirebbe la cpu nel suo ruolo di controlore e arbitro del sistema.
ed è per questo che cuda o chi per esso ha delle
funzioni per gestire agilmente i thread senza
andare con fork(); if (pid==0){..}else{..}
...
ci sono pure sistemi operativi che gestiscono i
thread, il fork riguardo il multiprocessing non
il multithreading, sono due cose completamente
differentiEhm ... NO! il multiprocessing è l'abilità di utilizzare più unità elaborative su una stessa macchina, il multi threading implica l'utilizzo di più thread nello scope di esecuzione di un programma; a a meno che scrivendo in C l'istruzione fork ti cresca una cpu in più sulla motherboard, esso è multithreading e non multiprocessing.
Fermo ... inverti .. Bravo, ora sai cosa vuole
fare intel, più o meno il contrario di quello
che
eri
convinto.
ecco, finiscila di dire XXXXXXXAh, mi sembra quasi che dovella mi abbia accusato di essere un M4 fanboy...
-
-
-
-
-
Il dominio delle DirectX
a differenza delle tradizionali architetture video, in Larrabee le funzionalità richieste dalle API DirectX sono implementate esclusivamente a livello di software. Tempo fa Intel ha citato come esempio la specifica Pixel Shader 5.0, che in Larrabee potrà essere supportata attraverso un semplice aggiornamento software (mentre le GPU tradizionali andranno riprogettate a livello hardware).Non avevo capito questa cosa, il fallimento di Larrabee è scontato.Le GPU andranno riprogettate a livello hardware?Puo' darsi, ma poi andranno n volte piu' veloci di Larrabee.MAH-
Re: Il dominio delle DirectX
e che c'entra la frase "il dominio delle directx"? mi pare che le gpu moderne supportino pure opengl-
Re: Il dominio delle DirectX
- Scritto da: iosonodio
e che c'entra la frase "il dominio delle
directx"? mi pare che le gpu moderne supportino
pure
openglIn realtà anche quelle non troppo "moderne". Il supporto opengl è già presente da anni su molte schede.Poi tutto dipende dagli utilizzi. Se rimaniamo nel campo gaming allora directx fa il 99%. In altri campi il discorso cambia.Comunque come già le schede attuali dimostrano, la vera chiave di sucXXXXX non è solo la GPU fine a se stessa, ma l'architettura complessiva della scheda, unita soprattutto alla bontà del driver abbinato.-
Re: Il dominio delle DirectX
nemmeno nel gaming, le directx hanno questo dominiopensa a playstation e wii tanto per citarne due....parliamo di miliardi di consolle che usano openglè che molti sono abituati a pensare informatica=pc=windows=ie=directx=....-
Re: Il dominio delle DirectX
- Scritto da: pabloski
nemmeno nel gaming, le directx hanno questo
dominio
pensa a playstation e wii tanto per citarne
due....parliamo di miliardi di consolle che usano
openglAh, non sapevo.Ma allora altro che 99%... se aggiungiamo i giochi per iPhone, direi che possiamo parlare di 0,99%, più che 99%...
-
-
Re: Il dominio delle DirectX
- Scritto da: Ste
Poi tutto dipende dagli utilizzi. Se rimaniamo
nel campo gaming allora directx fa il 99%. In
altri campi il discorso
cambia.Io direi che questo 99% sta scendendo a vista d'occhio...
-
-
-
