ITMI20080999A1 - Modulo di renderizzazione per grafica a due dimensioni - Google Patents

Description

DESCRIZIONE

SFONDO DELL’INVENZIONE

Campo di applicazione

La presente invenzione si riferisce ad un modulo di renderizzazione per grafica a due dimensioni (2D) ed, in particolare, avente una catena di processamento grafico o, in modo equivalente, una pipeline grafica, per la renderizzazione di scene bidimensionali (2D).

Descrizione dell’arte nota

La grafica computerizzata è la tecnica di generazione di immagini su un dispositivo hardware, quale ad esempio un display o una stampante, tramite computer. La generazione di immagini o oggetti da rappresentare su uno dispositivo di visualizzazione è comunemente chiamata renderizzazione (dall’inglese, rendering).

Nell’ambito della grafica bidimensionale (2D), è nota una pipeline grafica 2D di renderizzazione di immagini basata su un approccio di processamento dei dati in modo cosiddetto immediato (in inglese,

immediate mode rendering pipeline o, brevemente, IMR pipeline).

Per processamento di dati in modo immediato, s’intende un’elaborazione per l’appunto immediata dei dati e cioè nell’ordine in cui vengono ricevuti dalla pipeline grafica 2D ed una contestuale renderizzazione dei dati elaborati sullo superficie bidimensionale visualizzazione (display). Come intuibile, in un approccio di tipo immediato, ciascuno oggetto da visualizzare è elaborato e renderizzato sullo schermo indipendentemente dagli altri oggetti della scena.

La pipeline grafica 2D di tipo IMR presenta l’inconveniente di risultare poco efficiente in termini di occupazione di banda e costi nel caso in cui siano implementate operazioni sia volte a migliorare la qualità delle scene da visualizzare sia volte a ridurre il carico di lavoro della pipeline grafica stessa e quindi le prestazioni dell’applicazione grafica in cui la pipeline è impiegata.

Lo scopo della presente invenzione è proporre una pipeline grafica 2D di tipo alternativo a quella sopra menzionata atta a ridurne almeno parzialmente gli svantaggi in particolare per quanto riguarda l’occupazione di banda nonché di memoria della pipeline grafica e le prestazioni dell’applicazione grafica in cui la pipeline grafica stessa è impiegata.

SOMMARIO DELL’INVENZIONE

Tale scopo e tali compiti vengono raggiunti mediante un modulo grafico di renderizzazione in accordo con la rivendicazione 1 e da sue forme preferite di realizzazione come definite dalle rivendicazioni dipendenti da 2 a 19.

Forma oggetto della presente invenzione anche un sistema grafico come definito nella rivendicazione 20 e sua forma preferita di realizzazione come definita nella rivendicazione 21.

Forma oggetto della presente invenzione anche un metodo di renderizzazione come definito nella rivendicazione 22 e sua forma preferita di realizzazione come definito nella rivendicazione 23.

BREVE DESCRIZIONE DEI DISEGNI

Ulteriori caratteristiche e vantaggi del dispositivo secondo l’invenzione risulteranno dalla descrizione di seguito riportata di esempi preferiti di realizzazione, dati a titolo indicativo e non limitativo, con riferimento alle annesse figure, in cui:

- la figura da 1 illustra schematicamente un sistema grafico in accordo con un esempio di realizzazione;

- la figura da 2 illustra schematicamente un modulo grafico secondo un esempio dell’invenzione;

- la figura da 3 illustra una pipeline grafica impiegabile all’interno del modulo grafico della figura 2 secondo un esempio di realizzazione dell’invenzione;

- le figure 4 e 6 illustrano schematicamente una forma di realizzazione di uno schermo di visualizzazione su cui sono rappresentate entità grafiche di riferimento processate dalla pipeline grafica di figura 3;

- la figura 5 illustra schematicamente un esempio di organizzazione di un buffer di memoria interno alla pipeline grafica della figura 3;

- le figure 7 e 8 mostrano schematicamente diagrammi a blocchi rappresentativi delle operazioni principali svolte da un modulo di processamento della pipeline grafica della figura 3, e

- la figura 9 mostra schematicamente un diagramma a blocchi rappresentativo delle operazioni principali svolte da un ulteriore modulo di processamento della pipeline grafica della figura 3.

DESCRIZIONE DETTAGLIATA

La figura 1 mostra un sistema grafico 100 in accordo con un esempio di realizzazione dell’invenzione, includente un modulo grafico di renderizzazione 500 o anche pipeline grafica.

Il sistema grafico 100 della figura 1 è, ad esempio, un apparato di codifica/decodifica per televisione digitale conosciuto anche come set top box ma, in accordo con altre forme di realizzazione dell’invenzione, può essere un altro sistema grafico, quale un telefono mobile, un palmare PDA (Personal Digital Assistant), un dispositivo multimediale con schermo di tipo VGA (ricevitore digitale terrestre, lettori DVIX oppure lettore MP3), un computer (per esempio, un personal computer), una console di gioco (per esempio, PS3) e così via.

L’apparato di codifica/decodifica 100 è preferibilmente di tipo HDTV ovvero per applicazione nella televisione ad alta definizione (in inglese, High Definition TeleVision, HDTV).

L’apparato di codifica/decodifica 100 per televisione digitale è configurato per ricevere un flusso di dati codificati d’ingresso DATIN (dati video e/o audio) da un’antenna esterna 10 (ANT) al fine di fornire un corrispondente flusso di dati codificati DATOUT ad un apparato televisivo 20 (TV) munito di almeno un schermo di visualizzazione 30 (DISP) ed operativamente collegato all’apparato di codifica/decodifica 100.

In maggior dettaglio, l’apparato di codifica/decodifica 100 comprende un’unità centrale di processamento 40 (CPU, Central Processing Unit), ad esempio un microprocessore o un microcontrollore, operativamente collegato ad una memoria principale di sistema 50 (MEM).

L’apparato di codifica/decodifica 100 comprende inoltre un dispositivo d’ingresso/uscita 60 (IN/OUT) operativamente collegato e controllato dall’unità centrale di processamento 40 (CPU) al fine di ricevere il flusso di dati codificati d’ingresso DATIN.

In aggiunta, l’apparato di codifica/decodifica 100 comprende un dispositivo elettronico 70 (AH) predisposto alla crittazione/decrittazione di dati digitali. In maggior dettaglio, il dispositivo elettronico 70 è un acceleratore hardware operante sotto il controllo dell’unità centrale di processamento 40 al fine di decrittare il flusso di dati decodificati DATIN ricevuti dal dispositivo d’ingresso/uscita 60. Particolarmente, l’acceleratore hardware 70 è configurato per ricevere segnali d’attivazione dall’unità centrale di processamento 16 per decrittare il flusso di dati DATIN ed inviare dati decrittati DAT ad un decodificatore audio/video 80 (AU/VID) atto a fornire (sotto il controllo dell’unità centrale di processamento 40 alla quale è operativamente collegato) il flusso di dati codificati DATOUT all’apparato televisivo 20.

Il decodificatore audio/video 30 comprende il modulo grafico di renderizzazione 500 o semplicemente modulo grafico, già nominato in precedenza, il quale risulta operativamente collegato e controllato dall’unità centrale di processamento 16.

Il modulo grafico 500 è configurato per implementare un set di funzioni di tipo grafico per renderizzare una scena grafica 2D la cui descrizione è ricevuta in ingresso dall’apparato di codifica/decodifica 100 tramite l’antenna esterna 10, e quindi visualizzata sullo schermo di visualizzazione 30 dell’apparato televisivo 20, eventualmente sovrapponendo la scena grafica 2D ottenuta con il flusso di dati codificati DATAOUT, inviando il risultato all’apparato televisivo 20.

Preferibilmente, il modulo grafico 500 è un motore grafico configurato per renderizzare immagini digitali sgravando da aggiuntivi carichi di lavoro l’unità centrale di processamento 60. Ai fini della presente invenzione, per motore grafico s’intende un dispositivo in grado di renderizzare in hardware o in software non tramite esecuzione da parte dell’unità centrale di processamento ma tramite esecuzione da parte di un’altro co-processore quale, ad esempio, un processore di segnali digitali DSP (dall’acronimo inglese, Digital Signal Processor). La terminologia “acceleratore grafico” o “co-processore grafico”, anch’essi comunemente impiegati nel campo della grafica computerizzata, sono del tutto equivalenti al termine motore grafico.

Alternativamente, il modulo grafico 500 può essere un’unità di processamento grafico GPU (dall’acronimo inglese, graphic processing unit) in cui le funzioni di renderizzazione sono compiute sulla base di istruzioni software eseguite da un processore dedicato quale un DSP e sulla base di istruzioni hardware eseguite da una logica hardware specificatamente progettata. In accordo con una ulteriore forma di realizzazione, alcune o tutte le funzioni di renderizzazione sono compiute dall’unità centrale di processamento 16.

La figura 2 mostra un diagramma a blocchi del modulo grafico 500. In particolare, il modulo grafico 500 è configurato per renderizzare scene 2D (bidimensionali) sul display 30 dell’apparato televisivo 20.

Particolarmente, il modulo grafico 500 in accordo all’esempio dell’invenzione è predisposto per una renderizzazione di immagini 2D basata su un approccio di processamento dei dati in modo cosiddetto differito (in inglese, delayed mode). Inoltre, il modulo grafico 500 è preferibilmente configurato per risultare conforme allo standard aperto OpenVG, promosso all’interno di un gruppo di lavoro denominato Khronos, noto in letteratura.

Per processamento di dati con approccio di tipo in modo differito s’intende un processamento dei dati comprendente una prima elaborazione dei dati ricevuti in ingresso dal modulo grafico e la memorizzazione dei dati elaborati in una memoria interna al modulo grafico e, solo in seguito ad un apposito comando ricevuto dall’applicazione grafica, una seconda elaborazione finalizzata alla visualizzazione della scena sullo schermo sulla base dei dati precedentemente elaborati e renderizzati. Si noti che in un approccio in modo differito i dati vengono tipicamente processati in ordine differente rispetto a quello con cui vengono acquisiti dal modulo grafico, dipendente strettamente dall’applicazione grafica.

Si noti che il processamento dei dati basato su approccio in modo differito è noto in grafica 3D (tridimensionale) ed è alla base dell’architettura hardware di renderizzazione tipo sort-middle SMR (dall’acronimo inglese, Sort-Middle Rendering), di per sé nota all’esperto di grafica 3D ed anche conosciuta come architettura di renderizzazione basata su Tile (in inglese, Tile based rendering architecture).

Alla luce di quanto detto sopra, il modulo grafico 500 è da intendersi una pipeline grafica di tipo sort-middle per renderizzazione di scene bidimensionali.

Con riferimento ora alla figura 2, il modulo grafico 500 comprende un modulo pilota o driver 210, una prima pipeline grafica 2D 200 (in inglese, 2D graphics (GFX) pipeline), in seguito pipeline grafica, ed una seconda pipeline 2D di filtraggio 300 (in inglese, 2D filtering pipeline), in seguito pipeline di filtraggio.

Il modulo driver 210 è un modulo driver conforme allo standard 2D OpenVG (OpenVG Driver), di per sé noto, avente compiti d’interfaccia standard e configurato per ricevere comandi da programmi (ad esempio, interfaccia programmazione applicazione, in inglese Application Programming Interface, API) in esecuzione sull’unità centrale di processamento 60 e tradurre detti comandi in comandi specializzati per la pipeline grafica 200 e/o la pipeline di filtraggio 300.

Le informazioni generabili dal modulo driver 210 comprendono: un’entità geometrica (primitiva) di riferimento 2D denominata percorso (in inglese, path), in seguito semplicemente path; un contesto di una scena da renderizzare, in seguito semplicemente contesto (in particolare l’organizzazione del contesto riflette quella definita dallo standard OpenVG); un’immagine digitale (bitmap) di tipo VG (Vector Graphics image) di riferimento, in seguito semplicemente immagine bitmap VG.

Come noto al tecnico del ramo, un “path” è un’entità geometrica di riferimento della grafica 2D intesa come un insieme di comandi di tipo disegno (plotting) da fornire alla pipeline grafica 2D per definire il contorno di una primitiva 2D bidimensionale. In particolare, una scena 2D è definibile come un insieme di immagini VG di tipo bitmap e di path a cui sono associati uno o più contesti. Tale insieme è sottomesso alla pipeline grafica configurata per comporre o meglio renderizzare la scena 2D sullo schermo di visualizzazione 30. Ogni path sfrutta un meccanismo logico di tipo plotting che si concretizza nel tracciamento di un contorno della primitiva 2D che il path descrive da un punto di partenza ad un punto di arrivo.

A tal fine, si osservi inoltre che un path conforme allo standard OpenVG comprende un primo array di comando o segmento (data command o segment) rappresentativo del disegno o movimento da tracciare ed un secondo array di dati (data) rappresentativo delle coordinate X, Y del punto di arrivo in cui termina il disegno o il movimento e, per alcuni comandi, rappresentativo di uno o più punti di controllo, a seconda del particolare comando. Si noti che il punto di partenza è da considerarsi implicito: al primo comando presenta coordinate pari all’origine convenzionale della superficie su cui tracciare il disegno e ai successivi comandi presenta coordinate di volta in volta aggiornate e pari a quelle del punto di arrivo dell’ultimo comando eseguito. I dati del secondo array vengono processati in parallelo ai dati del primo array a seconda del comando in esso definito.

L’insieme esemplificativo dei principali comandi che possono essere indicati in un path comprende: MOVE TO, LINE TO, QUAD BEZIER TO, CUBIC BEZIER TO, ARC TO. A ciascun comando vanno associati i dati corrispondenti alle coordinate del punto di arrivo.

Ad esempio, il path “comando = MOVE TO; dati = X1, Y1” implica un salto dal punto di partenza o origine implicitamente raggiunto allo stato attuale della computazione (ad esempio di coordinate X0, Y0) al punto di arrivo di coordinate X1 e Y1. Il comando “MOVE TO” comporta uno spostamento sulla superficie ma non implica alcun tracciamento di contorno sulla superficie stessa. Il path “comando = LINE TO; dati = X1; Y1” comporta il tracciamento di una linea dal punto di partenza (ad esempio l’origine) al punto di arrivo specificato (X1, Y1); il path “comando = ARC TO; dati = X1, X1” comporta il tracciamento di un segmento di arco dal punto di partenza al punto di arrivo (X1, Y1).

Ad esempio, il path “comando = QUAD BEZIER TO; dati = X1, Y1; X2, Y2” comporta il tracciamento di una curva di Bezier di grado 2 (per l’appunto, quadratica) che passa tra il punto di partenza ed il punto di arrivo (X1, Y1). Il dato X2, Y2 rappresenta il punto di controllo e consente di definire, ad esempio, la particolare forma della curva di Bezier da disegnare.

Ritornando alle informazioni fornite dal modulo driver 210, per contesto s’intende un insieme di istruzioni e/o informazioni fornito dall’applicazione grafica 2D OpenVG per la renderizzazione di una scena, tipicamente destinata alla pipeline grafica 2D. Alcune istruzioni comprese tipicamente in un contesto 2D sono, ad esempio: istruzioni destinate al modulo di processamento path ovvero riempimento path (path fill), allargamento contorno path (path stroke, path stroke width); tipo di trasformazione prospettica da associare al modulo di processamento path; tipo di paint; tipo di anti-aliasing; tipo di immagine bitmap VG associato; tipo di equazione di blending, e così via.

Infine, risulta generabile dal modulo driver 210 anche l’informazione del tipo immagine bitmap VG per la quale s’intende un insieme di pixel adiacenti ciascuno avente un determinato colore. L’immagine bitmap è tale da essere ricevuta in ingresso dalla pipeline grafica 2D 200 ed essere disegna (renderizzata) direttamente sullo schermo in seguito ad una operazione di mappatura, eventualmente prospettica.

Ritornando al modulo grafico 500 della figura 2, si osservi che la pipeline grafica 200 è configurata per ricevere dal modulo driver 210 informazioni quali path, contesto ed immagini bitmap VG ed un ulteriore comando di DRAW PATH oppure DRAW IMAGE che indica alla pipeline stessa se l’entità da elaborare è un path oppure un’immagine bitmap VG.

La pipeline di filtraggio 300 è invece configurata per ricevere dal modulo driver 210 solamente contesto e immagini bitmap VG. A differenza della pipeline grafica 200, la pipeline di filtraggio 300 non è dunque predisposta a ricevere in ingresso entità geometriche di tipo path.

Si fa presente che, come sarà anche ribadito nel seguito, la pipeline grafica 2D 200 è internamente configurata comunque per elaborare entità di tipo path e non immagini bitmap VG pertanto, nel caso in cui l’entità da renderizzare sia proprio un’immagine bitmap VG, il modulo driver 210 è configurato per trasformare l’immagine bitmap VG in un path equivalente. In particolare, l’immagine bitmap VG è trasformata, preferibilmente, in quattro comandi (in particolare di tipo LINE TO) il cui path rappresenterà esattamente il bordo esterno (contorno) della immagine bitmap VG da disegnare.

Questa trasformazione eseguibile dal modulo driver 210 consente vantaggiosamente ad un utente di non dover necessariamente fornire un path corrispondente all’immagine bitmap VG ma di poter fornire al modulo grafico 500 direttamente immagini bitmap predisponendo preferibilmente un unico modulo driver sia per la pipeline grafica 200 (predisposta ad accettare sia path sia immagini bitmap VG) sia per la pipeline di filtraggio 300 del modulo grafico 500 (predisposta ad accettare solo immagini bitmap VG).

Con riferimento ora alla figura 3, viene ora descritta nel dettaglio la pipeline grafica 200.

La pipeline grafica 200 comprende uno stadio di processamento di path 220 (path stage), un modulo di rasterizzazione 230 (rasterizer), un primo modulo di processamento 240 (binner o raccoglitore), un secondo modulo di processamento parser 250 (parser o analizzatore), un buffer di memoria interna 260 (scene buffer), un processore di frammenti 270 (fragment processor), un modulo di memoria di macroblocco 280 (OnChip memory), un buffer di frame 290 (frame buffer).

Lo stadio di processamento di percorso 220, di per sé noto al tecnico esperto di grafica 2D, è configurato per ricevere in ingresso un path d’ingresso P dal modulo driver 210 (mostrato per chiarezza anche nella figura 3) e fornire al modulo di rasterizzazione 230 un path semplificato d’uscita P’ . Il path d’ingresso P risulta essere un path cosiddetto ad alto livello in quanto comprendente tutti i possibili comandi (descritti in precedenza) definibili da un path. Il path d’uscita P’ risulta essere un path cosiddetto di basso livello e, per l’appunto, semplificato rispetto al path d’ingresso P in quanto comprendente solo comandi di tipo MOVE TO o LINE TO. Il path semplificato P’ è comunemente chiamato anche bordo (EDGE), in seguito anche semplicemente EDGE.

Si noti che, preferibilmente, lo stadio di processamento di percorso 220 è a sua volta una micro-pipeline comprendente una serie di moduli di processamento (non mostrati nella figura 3) ciascuno dei quali è configurato per concorrere alla generazione del path semplificato d’uscita P’ a partire dal path d’ingresso P a seconda del contesto fornito dal modulo driver 210.

Ad esempio, lo stadio di processamento di percorso 220 comprende un modulo di tessellizzazione (tessellator), di per sé noto, configurato per trasformare il path d’ingresso P nel path d’uscita P’. Il path d’uscita P’ comprende anch’esso una serie di comandi (tipicamente impliciti) di tipo plotting (solamente LINE TO, MOVE TO) con i dati associati a dati rappresentativi di coordinate superficie o schermo (screen surface). Per coordinate superficie s’intendono coordinate mappabili direttamente in pixel sullo schermo.

Si osservi che lo stadio di processamento di percorso 220 è configurato per processare il path d’ingresso P’ in funzione delle istruzioni incluse nel contesto fornito dal modulo driver 210, ad esempio, un’istruzione di riempimento del path (path fill) oppure un’istruzione di allargamento del contorno del path (path stroke). Entrambe le istruzioni sopra indicate sono ben note al tecnico del settore.

In particolare, se il contesto comprende l’istruzione di riempimento del path (path fill), lo stadio di processamento di percorso 220 risulta predisposto per fornire al modulo di rasterizzazione 230 il path d’uscita P’ come generato dal modulo di tessellizzazione in quanto l’operazione di riempimento di un path è eseguita dal modulo di rasterizzazione 230. Nel caso in cui il contesto comprenda invece l’istruzione di allargamento del contorno del path (path stroke), lo stadio di processamento di percorso 220 risulta predisposto per eseguire sul path d’uscita P’ generato dal modulo di tessellizzazione un’operazione di allargamento del path P’, mediante operazioni di convoluzione ed allargamento sulla base di un’informazione di larghezza (width) fornita dal contesto in associazione all’operazione di allargamento del contorno del path. In questo scenario, lo stadio di processamento di percorso 220 risulta predisposto per fornire al modulo di rasterizzazione 230 un ulteriore path d’uscita P” come risultato dell’allargamento del path d’uscita P’.

Lo stadio di processamento di percorso 220, a seconda delle istruzioni contenute nel contesto, risulta pertanto configurato per fornire al modulo di rasterizzazione 230 il tipo di contorno (P’ o P”) su cui eseguire l’operazione di riempimento. Inoltre, lo stadio di processamento di percorso 220 risulta predisposto per svolgere, ad esempio, un’operazione di proiezione del path sullo schermo di destinazione mediante una matrice di trasformazione.

Il modulo di rasterizzazione 230 è un modulo di rasterizzazzione 2D AET (Active Edge Table Rasteriser), di per sé noto, che risulta operativamente associato allo stadio di processamento di percorso 220 e configurato per ricevere da esso il path d’uscita semplificato P’ oppure l’ulteriore path d’uscita P” (EDGE in coordinate superficie o schermo) e fornire in uscita in generale più entità grafiche di basso livello di tipo span S, in seguito semplicemente denominate span.

Come noto al tecnico di grafica 2D, con “span” s’intende un insieme di frammenti (fragment) dello schermo orizzontalmente adiacenti aventi la stessa copertura (coverage) rispetto al path semplificato (P’ o P”) in ingresso dal modulo di rasterizzazione 230. Per frammento s’intende in insieme di informazioni di pixel comprendente un set di attributi per ciascun pixel quali ad esempio colore e valori di coordinate. Per copertura s’intende la percentuale di sovrapposizione del frammento rispetto al path semplificato (P’ o P”). Il valore di copertura o coverage è definito come un numero compreso tra 0 e 1.

Un frammento incluso completamente all’interno del path ha sovrapposizione totale rispetto ad esso e pertanto percentuale di copertura pari al 100% (per definizione, valore di copertura = 1). Un frammento invece che si trova all’altezza del contorno del path (P’ o P”) ha, rispetto ad esso, sovrapposizione parziale e pertanto percentuale di copertura inferiore al 100 % (per definizione, valore di copertura < 1).

Con riferimento alla figura 4, viene ora descritto un esempio di generazione di span da parte del modulo di rasterizzazione 230. Si consideri uno schermo SCH, ad esempio il display 30 dell’apparato televisivo 20, suddiviso in una pluralità di fragment F. Il modulo di rasterizzazione 230 è configurato per generare una pluralità di span raggruppando frammenti adiacenti aventi lo stesso valore di copertura sulla base della valutazione di quanti frammenti sono sovrapposti parzialmente o totalmente ad un path semplificato (P’; P”) ricevuto dal modulo path 220. Nell’esempio della figura 4 il path semplificato è un ellisse (tipicamente descritta ad alto livello come un path P composto da due comandi di tipo arco). Si ribadisce che il modulo di rasterizzazione 230 non è configurato per ricevere in ingresso un ellisse in quanto tale , rappresentato dal path P direttamente, ma un path semplificato P’ (EDGE) ovvero un insieme di segmenti rettilinei rappresentativi di un’approssimazione dell’ellisse.

Gli span generabili dal modulo di rasterizzazione 230 possono essere di due tipi: span interno (internal span) ossia insieme di frammenti adiacenti fra loro interamente sovrapposti all’ellisse (valore di copertura pari a 1); span di bordo (border span) ossia insieme di fragment adiacenti parzialmente sovrapposti all’ellisse (stesso valore di copertura minore di 1). Si fa presente che nel caso di un path di forma ellittica è assai improbabile che vengano generati span di bordo comprendenti più di un singolo frammento.

Nell’esempio della figura 4, sono individuabili sei span interni (si1 comprendente 7 frammenti; si2 comprendente 13 frammenti; si3 comprendente 16 frammenti; si4 comprendente 16 frammenti; si5 comprendente 13 frammenti; si6 comprendente 8 frammenti) e quarantatre span di bordo (alcuni di essi indicati con il riferimento sb) ciascuno comprendente un singolo frammento.

Il modulo di rasterizzazione 230 è predisposto per definire la primitiva di tipo span tramite un insieme di dati comprendente: un primo dato YLINEA rappresentativo della linea dello schermo a cui lo span appartiene; un secondo dato XSTART rappresentativo della colonna in cui si trova il primo frammento dello span; un terzo dato SIZE (larghezza) rappresentativo della dimensione dello span in termini di numero di frammenti adiacenti a partire dal secondo dato XSTART. Con riferimento al primo span interno si1 della figura 4, esso risulta definito dal modulo di rasterizzazione 230 con l’insieme di dati YLINEA = 3; XSTART = 9; SIZE = 7.

Facendo nuovamente riferimento alla figura 3, il primo modulo di processamento 240 è configurato per suddividere la primitiva d’ingresso di tipo span ricevuto dal modulo di rasterizzazione 230 in primitive di tipo sotto-span ciascuna della quali risulta associata ad un macro-blocco rappresentativo dello schermo di visualizzazione SCH.

In particolare, il primo modulo di processamento 240 risulta predisposto per conoscere dal contesto fornito dall’applicazione grafica 2D un’informazione rappresentativa della dimensione di ciascun macro-blocco in cui risulta suddivisibile lo schermo di visualizzazione su cui renderizzare la scena.

Per definizione, un macro-blocco è una porzione dello schermo avente dimensione N x M, dove N ed M (preferibilmente potenze di due) rappresentano ciascuno un numero di pixel predeterminato dal contesto dell’applicazione grafica 2D. La dimensione del macro-blocco N x M è da considerarsi fissa in quanto caratteristica statica dell’architettura hardware finale (sistema grafico) a cui è destinato il modulo grafico 500.

Contestualmente alle primitiva d’ingresso di tipo span ed alla dimensione di un macro-blocco, il modulo binner 240 è configurato per ricevere un’informazione relativa al solo sotto-contesto (subcontest) del processore di frammenti 270.

Il primo modulo di processamento 240 risulta configurato per immagazzinare nel buffer di memoria 260 le informazioni relative alle primitive di tipo sotto-span e al relativo sotto-contesto sulla base della dimensione acquisita del singolo macro-blocco secondo un’organizzazione dell’area di memoria corrispondente al buffer di memoria 260 definita da una specifica struttura dati di cui si parlerà nel seguito.

In particolare, il primo modulo di processamento 240, acquisita l’informazione indicativa della dimensione N x M del singolo macroblocco, è configurato per la generazione di una struttura dati di tipo lista di visualizzazione (display list) associata a ciascun macro-blocco della scena da renderizzare tale da organizzare l’immagazzinamento di dati all’interno del buffer di scena 260 in maniera compatta e quindi in modo particolarmente vantaggioso.

Un esempio di struttura dati di tipo lista, indicato con il riferimento LST, è mostrato nella figura 5. La struttura dati di tipo lista LST è preferibilmente un array dinamico del buffer di scena 260 comprendente un array di puntatori di liste di visualizzazione DLH (display list header) ed una pluralità di array di liste di visualizzazione DL (display list). Ciascun array di lista di visualizzazione della pluralità DL è organizzata in porzioni o pezzi (chunk) di memoria a grandezza fissa fra loro concatenate.

Ciascun elemento dell’array di puntatori alle liste di visualizzazione DLH rappresenta un indirizzo di una porzione di memoria del buffer di scena 260 in cui è inclusa la prima porzione della lista di visualizzazione DL.

L’array di intestazione di liste di visualizzazione DLH è tipicamente allocato in una porzione iniziale dell’area di memoria corrispondente al buffer di scena 260. Il numero di elementi D dell’array di intestazione, rappresentativo della lunghezza dell’array di intestazione di liste di visualizzazione DLH, è calcolato dal primo modulo di processamento 240 implementando la seguente relazione:

D = ceiling(W/N) x ceiling(H/M) (1.0) Come definito dalla relazione (1.0) il valore D è funzione delle dimensioni del singolo macro-blocco (NxM) e della risoluzione dello schermo di visualizzazione (WxH). Si noti che la risoluzione dello schermo (WxH) è da intendersi quale risoluzione attuale dello schermo al momento in cui il primo modulo di elaborazione 260 implementa la relazione 1.0. Infatti, la risoluzione dello schermo potrebbe variare in accordo alla superficie di renderizzazione associata alla pipeline grafica 200 in particolari istanti della computazione. Per quanto riguarda il calcolo in sé si fa presente che il comando ceiling (tetto) rappresenta un arrotondamento all’intero superiore rispetto all’operazione di divisione indicato fra parentesi.

A titolo di esempio, supponendo che il macroblocco abbia dimensione fissa pari a (64x32) e la pipeline grafica 200 sia configurata per renderizzare una scena su uno schermo avente dimensione attuale pari a (800x600), il numero di elementi dell’array di puntatori a liste di visualizzazione (quindi anche il numero di lista di visualizzazione) è pari D = ceiling(800/64) x ceiling(600/32) = 13 x 19 = 247.

Per quanto riguarda una singola lista di visualizzazione, ciascuna porzione di una lista di visualizzazione comprende un numero fisso di elementi di lista DLE (nell’esempio della figura 5 pari a 10) ed un puntatore NC all’indirizzo di memoria del buffer scena 260 in cui è allocata la porzione di lista di visualizzazione della stessa lista di visualizzazione. Il primo modulo di elaborazione 240 è configurato per associare al puntatore NC di una porzione di lista di visualizzazione precedente l’indirizzo di memoria del buffer di scena 260 in cui è allocato la nuova porzione di lista di visualizzazione creata. Questo tipo di organizzazione è di tipo dinamico in quanto, vantaggiosamente, nel caso in cui una lista di visualizzazione DL sia completa, il primo modulo di processamento 260 è configurato per creare una nuova porzione di lista di visualizzazione da concatenare successivamente all’ultima porzione di lista di visualizzazione creata.

Questa organizzazione del buffer di scena in porzioni di liste di visualizzazione concatenate consente l’immagazzinamento da parte del primo modulo di processamento 240 di liste di visualizzazione in modo efficiente in quanto è possibile caricare le liste di visualizzazione da una memoria esterna (non mostrata nelle figure) in un buffer locale (buffer di scena).

Un elemento di lista di visualizzazione DLE è, ad esempio, una struttura dati a 32 bit in cui i 4 bit più significativi sono rappresentativi di un codice operativo (per un massimo di 16 differenti codici operativi definibili) mentre i restanti 28 bit sono rappresentativi di una semantica in accordo al codice operativo a cui sono associati.

Si osservi che la tipologia di codice operativo discrimina la tipologia di elemento di lista di visualizzazione. Ad esempio, nel caso in cui il codice operativo sia un puntatore ad un indirizzo di memoria in cui è allocato un determinato contesto precedentemente immagazzinato, i rimanenti 28 bit sono impiegati per immagazzinare il suddetto indirizzo di memoria. Secondo un altro esempio, il codice operativo può indicare una primitiva di tipo sotto-span (span suddiviso o clipped span) ed i rimanenti 28 sono impiegati per immagazzinare dati relativi al sotto-span. Un altro esempio di codice operativo può essere relativa alla codifica di un’operazione di masking, di per sé nota, di un macro-blocco. In questo caso i rimanenti 28 bit indicano la tipologia di operazione di masking. Altri esempi di codice operativo possono essere operazioni di cancellazione (clearing) di buffer di memoria o di macro-blocchi. In questo caso i 28 bit indicano l’area di memoria corrispondente da cancellare.

Il primo modulo di processamento 240, è inoltre configurato, in seguito alla creazione della struttura dati di tipo lista di visualizzazione, per immagazzinare un sotto-contesto associato all’istruzione “disegna” (DRAW) che può ricevere dall’applicazione grafica tramite il modulo driver 210.

Si noti che il sotto-contesto effettivo da immagazzinare nel buffer di scena è quello associabile al solo processore di frammenti 270.

Inoltre, si consideri che dal momento che uno stesso sotto-contesto è condivisibile da differenti primitive d’ingresso di tipo span, esso è immagazzinato nel buffer di scena 260 solo una volta ed associato a ciascuna primitiva di tipo span impiegando un rispettivo elemento di lista di visualizzazione della struttura di lista di visualizzazione comprendente un codice operativo di puntamento ed un indirizzo dell’area di memoria del buffer di scena in cui è allocato il sotto-contesto condiviso.

Si osservi inoltre che il sotto-contesto associato al processore di frammenti 270 è fornito dalle specifiche OpenVG e pertanto la sua massima dimensione è un’informazione nota a priori alla pipeline grafica 2D.

Ritornando al primo modulo di processamento 240, esso comprende un primo buffer di memoria locale di scrittura 241 per immagazzinare localmente il sotto-contesto.

Il primo modulo di processamento 240 è vantaggiosamente configurato per immagazzinare localmente (in una rappresentazione compatta dello stesso) il sotto-contesto nel primo buffer di memoria locale di scrittura 241 e, successivamente, una volta acquisito localmente il sotto-contesto, per trasferire ed immagazzinare il sotto-contesto nel buffer di scena 260 mediante un singolo accesso a memoria esterna. L’impiego del buffer di memoria locale di scrittura 240 è vantaggioso in quanto la dimensione del contesto non è nota a priori.

Si noti che la dimensione del sotto-contesto compattato può cambiare in funzione dei valori del contesto stesso. Infatti, come noto, nello standard OpenVG un path o un’immagine bitmap VG possono essere renderizzati con l’aggiunta di diverse opzioni quali, ad esempio, la definizione di un immagine specifica per una particolare primitiva.

Contestualmente, il primo modulo di processamento 240 è predisposto per immagazzinare in un proprio registro interno (non mostrato nelle figure) un indirizzo di memoria rappresentativo dell’area di memoria del buffer di scena in cui è immagazzinato il sotto-contesto. Il primo modulo di processamento 240 è configurato inoltre per associare questo indirizzo a ciascun span che riceverà dal modulo di rasterizzazione.

In aggiunta, si noti che il primo modulo di processamento 240 è predisposto per acquisire prima il sotto-contesto e successivamente le primitive di tipo span. Questo consente, vantaggiosamente, al primo modulo di processamento 240, di associare a ciascuna primitiva d’ingresso di tipo span il sottocontesto di riferimento e di immagazzinare questa informazione in ciascuna delle liste di visualizzazione di ciascun macro-blocco intersecanti la primitiva d’ingresso di tipo span.

Si ribadisce che il primo modulo di processamento 240 è configurato per ricevere dal modulo di rasterizzazione 230 le primitive d’ingresso di tipo span da esso generate in accordo con la primitiva di tipo path da renderizzare. In particolare, tali primitive d’ingresso di tipo span sono sottomesse al primo modulo di processamento 240 secondo un ordine di linea crescente (dalla linea iesima alla linea i+1-esima).

Con riferimento ora alla figura 6, si consideri ad esempio una porzione dello schermo di visualizzazione SCH’ suddivisa in otto macro-blocchi M0-M7 ciascuno dei quali a dimensione 4x4. Si ribadisce che la dimensione dei singoli macro-blocchi è fissa in quanto definito a priori a livello di sistema ed è espressa in numeri di frammenti.

Il primo modulo di processamento 240 è configurato per associare, convenzionalmente, all’angolo in basso a sinistra della porzione di schermo SCH’ le coordinate 0, 0 ed associare a ciascuna linea di frammenti dello schermo un riferimento numerico progressivo a partire dal basso (linea 0, …, linea 4, linea 5, linea 6, …) ed a ciascuna colonna un indice progressivo a partire da sinistra (…, 6, 7, …, 11, 12, …).

Al momento della ricezione della primitiva d’ingresso di tipo span S1, il primo modulo di processamento 240 è configurato per suddividere (in inglese, to clip) la primitiva d’ingresso di tipo span S1 in una o più primitive di tipo sotto-span (in seguito, per brevità, semplicemente sotto-span) in accordo ai macro-blocchi di pertinenza a cui la primitiva d’ingresso di tipo span si sovrappone.

Per definizione, una primitiva di tipo sottospan è una porzione di una primitiva di tipo span associata univocamente ad uno ed uno solo macroblocco dello schermo di visualizzazione ed le informazioni ad esso riferiti sono inserite all’interno della struttura di lista di visualizzaione associata a quel macro-blocco.

Con riferimento alla figura 6, dal momento che la primitiva d’ingresso di tipo span s1 è sovrapposta ad un primo macro-blocco M5, un secondo macro-blocco M6 ed un terzo macro-blocco M7, il primo modulo di processamento 240 risulta atto a suddividere (in inglese, to clip) lo span d’ingresso S1 in un primo sotto-span SP1 definito all’interno del primo macroblocco M5, un secondo sotto-span SP2 definito all’interno del secondo macro-blocco M6 ed un terzo sotto-span SP3 definito all’interno del terzo macro blocco M7.

Conseguentemente, il primo modulo di processamento 240 è configurato per immagazzinare le informazioni relative al primo sotto-span SP1 all’interno della struttura dati di lista di visualizzazione associata al primo macro-blocco M5, le informazioni relative al secondo sotto-span SP2 all’interno della struttura dati di lista di visualizzazione associata al secondo macro-blocco M6, le informazioni relative al terzo sotto-span SP3 all’interno della struttura dati di lista di visualizzazione associata al terzo macro-blocco M7. Le operazioni implementate dal primo modulo di processamento 240 per organizzare la struttura dati di lista di visualizzazione per immagazzinare i sotto-span saranno descritte nel seguito.

Il primo modulo di processamento 240 è inoltre predisposto per immagazzinare in ciascuna struttura dati di lista di visualizzazione associato al rispettivo macro-blocco, prima dell’immagazzinamento delle informazioni del corrispondente sotto-span, anche un riferimento (puntatore o indirizzo di memoria) al sotto-contesto compattato del processore di frammenti 270.

Per quanto riguarda l’immagazzinamento all’interno della rispettiva struttura dati di lista di visualizzazione di un sotto-span, si consideri che un sotto-span rappresenta un elemento di lista di visualizzazione. In particolare, i 28 bit riservati ai dati dell’elemento di lista di visualizzazione nel caso di sotto-span sono organizzabili, ad esempio, come segue:

s bit riservati per immagazzinare un valore di dimensione del sotto-span (nell’esempio della figura 6 s è pari a 13 bit);

28-s bit riservati per immagazzinare un valore di offset del sotto-span. Per offset di un sotto-span s’intende la distanza in termini di numero di frammenti del primo frammento del sotto-span dall’origine relativa del singolo macro-blocco (convenzionalmente il frammento nell’angolo alto a sinistra del macro-blocco).

Facendo riferimento nuovamente all’esempio di figura 6, si fa presente che l’insieme di dati XSTART, YLINEA e SIZE della primitiva d’ingresso di tipo span S1 sono indicate facendo riferimento alle coordinate dello schermo intero. Da questo ne consegue che essendo XSTART pari a 6, YLINEA pari a 6 e SIZE pari a 7, lo span d’ingresso S1 ha punto di partenza di coordinate schermo (6, 6) e punto di arrivo di coordinate schermo (12, 6). Si ribadisce che convenzionalmente l’origine del sistema di coordinate è l’angolo in basso a sinistra.

Sulla base di queste informazioni, il primo modulo di processamento 240 è configurato per calcolare un identificativo IDP del macro-blocco dello schermo che include il punto di partenza dello span S1 ed un identificativo IDA del macro-blocco dello schermo includente il punto di arrivo dello span S1 implementando la seguente relazione:

ID = (Y/M) x NML (X/N) (1.1)

in cui ID rappresenta l’identificativo da calcolare; N x M rappresentano le dimensioni del macro-blocco; (X, Y) sono le coordinate del punto di inizio o di fine dello span di cui si vuole calcolare l’identificativo del macro-blocco in cui è contenuto; NML è il numero di macro-blocchi per linea (nell’esempio di figura 6 pari a 4).

Nell’esempio della figura 6, l’identificativo IDI del macro-blocco (avente dimensione 4 x 4) includente il punto di inizio (di coordinate 6; 6) dello span S1 è calcolato implementando la relazione (1.1) come segue:

IDI = (6/4) x 4 (6/4) = 5 Æ il punto di inizio dello span S1 è contenuto nel macro-blocco M5 (vedere figura 6).

L’identificativo IDF del macro-blocco includente il punto di fine (di coordinate 12; 6) dello span S1 è calcolato implementando la relazione (1.1) come segue:

IDF = (6/4) x 4 (12/4) = 7 Æ il punto di fine dello span S1 è contenuto nel macro-blocco M7 (vedere figura 6).

Una volta calcolati l’identificativo del macroblocco (M5) che include il punto di inizio dello span S1 e l’identificativo del macro-blocco (M7) che include il punto di fine dello span S1, il primo modulo di processamento 240 conosce tutti i macroblocchi che includono lo span d’ingresso S1 (nell’esempio della figura 6, i macro-blocchi M5, M6 e M7).

Il primo modulo di processamento 240 è predisposto per organizzare il buffer di scena secondo una struttura dati di tipo lista di visualizzazione associata a ciascuno dei suddetti macro-blocchi. In particolare, le informazioni relative all’indirizzo di memoria in cui è immagazzinato il sotto-contesto ed ai sotto-span sono immagazzinati nelle liste di visualizzazione che iniziano dal macro-blocco includente il punto di inizio dello span S1 e che terminano nel macro-blocco includente il punto di fine dello span S1. Inoltre, per ogni sotto-span in cui è suddiviso lo span d’ingresso S1, la struttura dati di lista di visualizzazione andrà riempita con elementi di lista rappresentativi del valore di dimensione e del valore di offset del corrispondente sotto-span di pertinenza.

Si osservi pertanto che per ciascun macroblocco a cui si sovrappone lo span d’ingresso S1, il primo modulo di processamento 240 è configurato per creare ed immagazzinare, nella struttura dati di lista di visualizzazione associata ad un macroblocco intersecato dallo span d’ingresso S1, un sotto-span.

Come detto in precedenza, un sotto-span è identificabile dal valore di dimensione e dal valore di offset.

Al fine del loro calcolo, il primo modulo di processamento 240 è predisposto per implementare le seguenti relazioni:

offset = (Y % M) x N Xstart % N (1.2) nel caso in cui l’identificativo ID del macroblocco sia uguale all’identificativo IDI del macroblocco includente il punto di inizio dello span d’ingresso; in caso contrario al valore di offset è assegnato il valore 0;

offsetEnd = (Y % M) x N Xend % N (1.3) nel caso in cui l’identificativo del macro-blocco ID sia uguale all’identificativo del macro-blocco IDF includente il punto di fine dello span d’ingresso; in caso contrario al valore offsetEnd è assegnato il valore (N-1). Il valore offsetEnd indica l’ultimo frammento del sotto-span calcolato in numeri di frammenti a partire dall’origine del singolo macroblocco;

dimensione = offsetEnd – offset 1 (1.4) Nelle relazioni (1.2) e (1.3) N e M sono le dimensioni del singolo macro-blocco; Xstart è la coordinata X del punto di inizio dello span d’ingresso; Xend è la coordinata X del punto di fine dello span d’ingresso; il simbolo “%” indica il resto della divisione intera.

Nell’esempio della figura 6, applicando le relazioni (1.2), (1.3) ed (1.4) si ottiene quanto indicato nel seguito:

offset(SP1) = (6%4) x 4 (6%4)= 8 2 =10;

size(SP1) = ((6%4) x 4 3) – 10 1 = 11 – 10 1 = 2

offset(SP2) = (6%4) X 4 0 = 8 0 = 8 size(SP2) = ((6%4) x 4 3) – 8 1 = 11 –8 1 = 4

offset(SP3) = (6%4) x 4 0 = 8 0 = 8 size(SP3) = ((6%4) x 4 0) – 8 1 = 8 – 8 1 = 1

Nel caso in cui lo span d’ingresso S1 sia uno span cosiddetto di bordo (border span), il rispettivo di copertura è aggiunto in fondo alla lista di visualizzazione, in seguito alle informazioni relative al codice operativo, al valore di offset ed al valore di dimensione del sotto-span. Pertanto uno span di bordo ha necessità di almeno 64 bit di informazioni per essere memorizzato. Nel caso di span interno si ha bisogno invece di soli 32 bit di informazioni, come già detto in precedenza in quanto essendo lo span interno il suo valore di copertura è implicitamente definito pari ad 1.

Il primo modulo di processamento 240 implementando le relazioni (1.2), (1.3) ed (1.4) è configurato per calcolare i dati ed immagazzinare in maniera compatta tutti gli span d’ingresso ricevuti in una rappresentazione per sotto-span (in inglese, clipped span).

Ai fini della presente descrizione, la generale operazione di compattazione svolta dal primo modulo di processamento 240 implica l’operazione di suddivisione dello span d’ingresso in sotto-span e , per ciascuno di essi, il calcolo del valore di offset ed il valore di dimensione.

In un’ulteriore forma di realizzazione dell’invenzione, il primo modulo di processamento 240 è configurato per il pre-processamento di alcuni step di un algoritmo di scarto o culling di primitive di tipo sotto-span che, principalmente, è implementato, come sarà descritto dettagliatamente nel seguito, dal secondo modulo di processamento 250. Questo preprocessamento è possibile dal momento che già a livello del primo modulo di processamento 240 è conosciuto il contesto impostato dall’applicazione grafica e pertanto è possibile stabilire se uno span d’ingresso è di tipo occluso o occludente. Per definizione, uno span di bordo (valore di copertura < 1) non può essere considerato di tipo occludente.

Nel caso di span interno (valore di copertura = 1) se non sono contestualmente verificate particolari condizioni di impostazione del contesto, lo span interno è da considerarsi span non occludente. Nel caso in cui dette condizioni siano invece verificate, lo span interno è da considerarsi come occludente.

Le suddette condizioni relative al sottocontesto del processore di frammenti e relative allo span sono, preferibilmente, le seguenti:

- equazione di blending (di per sé nota) impostata a “VG_BLEND_SRC”;

- Vgmasking (di per sé nota) disabilitata;

- valore di copertura dello span uguale a 1 (questo condizione conferma che nessun span di bordo potrà essere considerato come occludente).

Se sono verificate le suddette condizioni, lo span è marcato come occludente, ad esempio, impiegando uno dei 16 codici operativi disponibili nei dati della lista di visualizzazione.

In pratica, uno span può essere marcato come occludente solo nel caso in cui il colore di un frammento dello span sovrascrive completamente qualsiasi altro colore immagazzinato in precedenza all’interno buffer di frame.

Il marcamento di uno span come occludente o meno consente, vantaggiosamente, alla pipeline grafica 200, ricevuto dall’applicazione grafica il comando SHOW (mostra), di processare quanto catturato ed immagazzinato nel buffer di scena da parte del primo modulo di processamento 240 visualizzando solo gli span occludenti e non quelli occlusi in quanto nascosti.

Con riferimento ora diagramma a blocchi della figura 7, viene ora riassunto schematicamente un esempio di pre-processamento di un algoritmo di scarto o culling da parte del primo modulo di processamento 240.

Il primo modulo di processamento 240 è configurato per: ricevere uno span d’ingresso (fase IN-S) e controllare se lo span d’ingresso ricevuto è occludente (fase OCC-S). In particolare si fa presente che al momento dell’immagazzinamento nel buffer di scena del sotto-contesto del processore di frammenti, nel caso in cui siano verificate le due condizioni di contesto indicate in precedenza (equazione di blending impostata a “VG_BLEND_SRC” e Vgmasking), viene altresì immagazzinato un flag pari al valore TRUE per indicare che lo span che si sta processando potrebbe essere uno span occludente nel caso sia verifica la condizione di span interno (valore di copertura paria 1). La terza condizione è computata al momento dell’immagazzinamento nel buffer di scena dello span.

Nel caso di risposta affermativa (fase OCC-S) lo span d’ingresso viene marcato come occludente (fase CS-O) ed il primo modulo di processamento è pronto a ricevere lo span d’ingresso successivo. Nel caso invece di risposta negativa il primo modulo di processamento si appresta a ricevere un nuovo span d’ingresso.

Con riferimento alla figura 8, viene ora riassunto schematicamente il flusso di operazioni implementate dal primo modulo di processamento 240 (ad esclusione dell’operazioni relative al preprocessamento dell’algoritmo di scarto o culling).

Il primo modulo di processamento è configurato per ricevere un dato d’ingresso (fase IN-D) e controllare se il dato d’ingresso è un contesto di scena (sotto-contesto del processore di frammento) oppure uno span d’ingresso (fase CON-S).

Nel caso in cui il dato d’ingresso sia un contesto, il primo modulo di processamento 240 è predisposto per immagazzinare il contesto nel primo buffer locale di scrittura 241 (fase SC-L) e successivamente nel buffer di scena 260 (fase SC-B). In seguito, il primo modulo di processamento 240 è configurato per immagazzinare in un apposito registro l’indirizzo dell’area di memoria in cui è immagazzinato il contesto (fase SC-R). Come ultima operazione viene altresì controllato se il contesto prevede l’abilitazione dell’algoritmo di scarto o culling (fase EN-OC) prima di ritornare a processare il successivo dato d’ingresso (fase IN-D).

Nel caso invece in cui il dato s’ingresso sia una primitiva di tipo span, il primo modulo di processamento 240 è configurato per suddividere lo span d’ingresso in primitive di tipo sotto-span in accordo con i macro-blocchi dello schermo di visualizzazione che vengono sovrapposti dallo span d’ingresso (blocco CP-S)- In seguito, viene effettuato un controllo per stabilire se un sottospan è da immagazzinare o meno nel buffer di scena 260 (blocco CHK-I). Nel caso in cui il sotto-span non sia da immagazzinare allora il primo modulo di processamento 240 si appresta a ricevere un successivo dato d’ingresso (blocco IN-D). Nel caso in cui il sotto-span sia da immagazzinare, allora il primo modulo di processamento 240 procede a calcolare il valore di offset ed il valore di dimensione del sotto-span implementando le relazioni (1.2)-(1.4) (blocco CL-OD). I valori di offset e dimensione vengono inseriti nella lista di visualizzazione del macro-blocco in cui è incluso il sotto-span contestualmente all’indirizzo di memoria in cui è immagazzinato il sotto-contesto (precedentemente processato) (blocco CON-DL). Successivamente, se il flag del sotto-span è pari al valore TRUE ed il sotto-span ha valore di copertura pari a 1, allora il sotto-span è marcato come sotto-span occludente (blocco MS-O). In seguito, il sotto-span è inserito nella rispettiva lista di visualizzazione (blocco IS-DL) ed il primo modulo di processamento 240 si predispone per ricevere il successivo dato d’ingresso (blocco CHK-I, blocco IN-D).

Facendo nuovamente riferimento alla figura 3, il secondo modulo di processamento 250 risulta operativamente associato al buffer di scena 260 per condividere in lettura quanto scritto dal primo modulo di processamento 240. Si noti che il primo 240 e secondo 250 modulo di processamento condividono anche segnali di sincronismo SC, di per sé noti.

In particolare, il primo modulo di processamento 240 è configurato per catturare (capture) i dati relativi al contesto (o sottocontesto) della scena da renderizzare ed i dati relativi alle primitive di tipo span come ricevuti dal modulo di rasterizzazione 230 ed immagazzinarli in una rappresentazione compatta (sotto-span associati a rispettivi macro-blocchi dello schermo). Il secondo modulo di processamento 250 è configurato per svolgere il ruolo opposto o duale a quello del primo modulo di processamento 240. In particolare, leggere i dati immagazzinati nel buffer di scena 260 e, procedendo secondo un predeterminato ordine dei macro-blocchi, a re-impostare il sottocontesto del processore di frammenti e individuare gli span immagazzinati in esso.

Inoltre, il secondo modulo di processamento 250 è configurato, vantaggiosamente, per implementare un algoritmo di scarto o culling di primitive occluse al fine di ridurre, come verrà ribadito anche nel seguito, il carico di lavoro del processore di frammenti.

Si noti che il processamento dei dati da parte del secondo modulo di processamento 250 ha inizio nel momento in cui l’applicazione grafica, tramite il modulo di driver 210, fornisce alla pipeline grafica 200 il comando di mostrare sullo schermo la scena renderizzata (comando SHOW (mostra)). Contestualmente al comando di SHOW possono essere forniti ulteriori comandi, previsto dallo standard OpenVG, che indicano di procedere con lo svuotamento della pipeline grafica 200 (processamento dei dati immagazzinati all’interno del buffer di scena).

Si osservi che, come noto, una pipeline grafica di sort-middle è configurata per il processamento reale dei dati della scena precedentemente catturata solo al ricevimento dall’applicazione grafica di uno dei suddetti comandi.

Si consideri inoltre che, dal momento che ciascun macro-blocco in cui è suddivisibile lo schermo di visualizzazione è indipendente dagli altri macro-blocchi, i moduli della pipeline grafica 200 a valle del primo modulo di processamento (ad esempio, il secondo modulo di processamento 250, il processore di frammenti 270, il modulo di memoria di macroblocco) sono configurati per lavorare vantaggiosamente in parallelo.

Ritornando al secondo modulo di processamento 250, esso comprende un secondo buffer locale di scrittura 251 per immagazzinare la lista di visualizzazione i-esima corrispondente al macroblocco i-esimo letto ed estratto dal buffer di memoria di scena 260 da parte del secondo modulo di processamento 250.

Si noti che, vantaggiosamente, in una forma di realizzazione alternativa, è possibile immagazzinare nel secondo buffer locale di scrittura 251 una porzione della lista di visualizzazione associata al macro-blocco aumentando così facendo le prestazioni della pipeline grafica 200.

Il secondo modulo di processamento 250 è inoltre configurato per caricare un contesto corrente di una regione di un macro-blocco sotto processamento da ulteriori buffer di memoria esterni al secondo modulo di processamento (ad esempio, un buffer di alpha-mask ed un buffer di frame) in nel modulo di memoria di macro-blocco 280.

Si osservi che nei suddetti ulteriori buffer esterni potrebbero essere immagazzinati dati utili per la rappresentazione dei macro-blocchi quali, ad esempio, immagini di sfondo precedentemente processate dalla pipeline di filtraggio 300 (figura 2). Infatti, tipicamente, il modulo grafico 500 è predisposto, vantaggiosamente, per caricare i dati processati dalla pipeline di filtraggio 300 prima che la pipeline grafica 200 procede alla renderizzazione della scena.

Si consideri inoltre che, ad esempio, nel caso in cui sia impiegato dall’applicazione grafica un algoritmo di anti-aliasing basato su super risoluzione (super resolution), di per sé noto, il modulo di memoria di macro-blocco 280 interno alla pipeline grafica 200 è considerato in super risoluzione campionata (super sampled resolution).

Si ricorda che un algoritmo di anti-aliasing consente di migliorare la visualizzazione dei contorni di una scena in modo che gli stessi contorni siano il più possibile sfumati e non a tratti. Ciò si ottiene tipicamente aumentando la risoluzione dello schermo durante l’elaborazione dei dati da renderizzare. Ad esempio, questo aumento della risoluzione può essere pari a quattro volte la risoluzione dello schermo. In questo caso il buffer di frame non ha la stessa risoluzione dello schermo ma è predisposto per lavorare in super risoluzione. Pertanto la scena è renderizzata facendo riferimento ad uno schermo più grande (buffer di frame in super risoluzione) ed al comando di mostra la scena (SHOW) da parte dell’applicazione grafica, ciascun pixel dello schermo (risoluzione originale 1X) avrà un colore dato dalla media del colore di quattro pixel spazialmente organizzati in una griglia di tipo 2x2 del buffer di frame (super risoluzione 4X). Facendo in questo modo i contorni di una scena risulteranno sfumati e non seghettati aumentando di fatto la qualità della scena visualizzata sullo schermo.

Nel caso di algoritmo di anti-aliasing abilitato, un filtro di up-sample (ottenuto replicando il colore dei pixel), di per sé noto, è adottato quando si caricano i dati dal buffer di frame. L’applicazione del filtro up-sample è necessario in quanto i dati caricati da un buffer esterno fanno riferimento sempre alla risoluzione originale 1X (grande quanto lo schermo) mentre internamente il modulo di memoria di macro-blocco interno di tipo OnChip fa riferimento ad una super risoluzione (ad esempio quadrupla o 4X). Pertanto, il filtro up-sample è predisposto per replicare il colore di un pixel caricato da un buffer esterno in quattro pixel adiacenti del modulo di memoria interno di tipo onChip.

Nel caso invece la funzione di alpha masking è disabilitata o il buffer di alpha mask non è impiegato, il caricamento di macro-blocchi con alpha mask potrebbe essere evitato.

Ancora, nel caso in cui, ad esempio, una prima istruzione contenuta nella lista di visualizzazione di un macro-blocco sia colore di riempimento e pulizia totale (full color clear), si può evitare di caricare informazioni dal buffer esterno in quanto poi saranno comunque coperti da questo colore.

Il secondo modulo di processamento 250 è inoltre configurato per implementare un algoritmo di scarto o culling delle primitive di tipo span occlusi immagazzinati all’interno della lista di visualizzazione sotto processamento e relativa al macro-blocco caricato.

Il secondo modulo di processamento 250 è predisposto semplicemente come un filtro atto a stabilire se lo span è di tipo occluso o meno. A tal fine, il secondo modulo di processamento 250 comprende, vantaggiosamente, una buffer locale di bit di maschera (bitmask) 252 avente preferibilmente dimensione pari N x M e cioè pari a quella di ciascun macro-blocco. Il buffer locale di bit di maschera 252 è un buffer ad un bit che, inizialmente (cioè all’inizio del processamento del macro-blocco corrente), è supposto essere uguale a zero.

Il secondo modulo di processamento 250 è configurato per processare la lista di visualizzazione in un ordine di tipo inverso dal momento che per come è stata scritta la lista di visualizzazione dal primo modulo di processamento 240 è da ritenersi valida la regola secondo cui l’ultimo span scritto nella lista di visualizzazione è tale da sovra scrivere tutti gli span precedenti. Pertanto il secondo modulo di processamento 250 è arrangiato per processare la lista di visualizzazione relativa ad un singolo macro-blocco cominciando dall’ultimo elemento della lista di visualizzazione immagazzinato nel buffer di scena 260 e terminando con il primo elemento immagazzinato nella stessa.

Con riferimento al diagramma a blocchi della figura 9, si ribadisce che il buffer locale di bit di maschera è impostato a zero (blocco BIM-0).

Il secondo modulo di processamento 250 è configurato per ricevere in ingresso uno span d’ingresso letto dalla lista di visualizzazione del macro-blocco sotto processamento (blocco IN-SD) e per controllare se lo span d’ingresso risulta completamente occluso o meno (blocco S-FO). In particolare, il secondo modulo di processamento 250 è atto a verificare se tutti i bit del buffer locale di bit di maschera che si sovrappongono allo span in processamento (in accordo con i suoi rispettivi valori di offset e dimensione letti dalla lista di visualizzazione) sono tutti impostati, ad esempio, al valore 1.

Si noti che la condizione bit del buffer locale di bit di maschera impostati a 1 implica che in precedenza è stato letto dalla lista di visualizzazione e pre-processato uno span di tipo occludente. Considerando che, come specificato in precedenza, il processamento dei dati è effettuato in ordine inverso, lo span processato in precedenza (che in realtà sulla scena sarà renderizzato davanti allo span in processamento) sarebbe già stato renderizzato come span occludente e quindi lo span in processamento è da considerarsi occluso. Si ribadisce che il secondo modulo di processamento 250 riesce a raggiungere questa conclusione implementando l’algoritmo di scarto o culling in quanto, vantaggiosamente, il buffer locale di bit di maschera 252 è impostato a uno.

Nel caso in cui almeno un bit del buffer locale di bit di maschera 252 che si sovrappone allo span in processamento è pari a 0 allora il secondo modulo di processamento 250 è tale da considerare lo span in processamento come parzialmente visibile.

Nel caso invece in cui tutti i bit del buffer locale di bit di maschera 252 che si sovrappongono allo span in processamento sono pari a 0, allora il secondo modulo di processamento 250 è tale da considerare lo span in processamento come completamente visibile.

In maggior dettaglio, nel caso in cui lo span sia considerato completamente occluso, il secondo modulo di processamento 250 è configurato per marcare lo span in processamento come “SPAN DA NON PROCESSARE” modificando il codice operativo ad esso associato (blocco MS-K) ad un predeterminato valore e per proseguire il processo di renderizzazione dei dati andando a ricevere lo span d’ingresso successivo (blocco IN-DS).

Nel caso in cui lo span in processamento sia considerato completamente visibile, il secondo modulo di processamento 250 è predisposto per controllare se esso sia uno span di tipo occludente (codice operativo rappresentativo di “SPAN OCCLUDENTE”) (blocco SP-OC). In caso affermativo, il secondo modulo di processamento 250 è configurato per aggiornare al valore 1 i bit del buffer locale di bit di maschera 252 che si sovrappongono allo span in processamento (blocco UP-BM).

Nell’ultimo caso in cui lo span in processamento sia considerato parzialmente visibile, il secondo modulo di processamento 250 è configurato per controllare se si tratta di uno span occludente (blocco SP-OC) ed, in caso affermativo, per aggiornare il buffer locale di bit di maschera 252 (blocco UP-BM) di conseguenza. In aggiunta, il secondo modulo di processamento 250 è predisposto per eseguire un’operazione di accorciamento (in inglese, shrinking) dello span nel caso in cui solo gli estremi dello span risultino occlusi (blocco SH-SP). Tale operazione di accorciamento consiste nel rimuovere dallo span i bit più a destra o più a sinistra rappresentativi degli estremi nel caso in cui siano occlusi ovvero si sovrappongano a bit del buffer locale di bit di maschera 252 aventi valore pari a 1. Nel caso in cui tali estremi siano di tipo occluso e lo span parzialmente occludente, il secondo modulo di processamento 250 è configurato per aggiornare il buffer locale di bit di maschera 252.

Si ricorda che quanto descritto finora con riferimento al diagramma a blocchi della figura 9 si riferisce ad un primo pre-processamento dei dati estratti da una lista di visualizzazione in un ordine cosiddetto inverso in modo tale da consentire, vantaggiosamente, il marcamento di tutti gli span completamente occlusi. Il secondo modulo di processamento 250 è configurato quindi per processare effettivamente la lista di visualizzazione relativa a ciascun macro-blocco dello schermo scartando tutti gli span con codice operativo “SPAN DA NON PROCESSARE” contestualmente al contesto ad essi associati. Ciò consente di ridurre notevolmente i tempi di computazione e la banda.

In maggior dettaglio, dopo il pre-processamento dell’algoritmo di scarto o culling degli span occlusi, il secondo modulo di processamento 250 è configurato per eseguire il processamento vero e proprio della lista di visualizzazione caricata che può essere pertanto letta correttamente seguendo un ordine naturale ovvero dall’inizio fino al raggiungimento della sua fine.

In particolare, quando è letto un elemento di lista di visualizzazione avente un codice operativo rappresentativo di un contesto, tale contesto è letto dal buffer di scena 260 a partire dall’indirizzo di memoria immagazzinato nel campo a 28 bit dell’elemento lista di visualizzazione correntemente letto (puntatore al contesto).

Si noti che la lettura del contesto consiste semplicemente nell’impostare il contesto locale del processore di frammenti 270 utilizzando come valori correnti quelli letti dal buffer di scena 260.

Una volta impostato il contesto, il secondo modulo di processamento 250 è configurato per leggere uno o più elementi della lista di visualizzazione rappresentativi di un sotto-span (nel caso di sottospan interno si legge un elemento di 32 bit; nel caso di sotto-span di bordo si leggono due elementi: 32 bit per valore di offset e dimensione e 32 bit per il valore di copertura).

A partire da detti valori di offset e dimensione e nota la dimensione di un singolo macroblocco(N x M), il secondo modulo di processamento 250 è configurato per calcolare le coordinate del punto di inizio (Xstart; Ystart) e del punto di fine (Xend; Yend) dello span implementando le seguenti relazioni matematiche:

Ystart = Yend = blockOffsetY offset/N (1.5)

Xstart = blockOffsetX offset % N (1.6)

Xend = Xstart dimensione (1.7)

in cui

blockOffsetX = i x N (1.8)

blockOffsetY = j x M (1.9)

dove con i e j indicano le coordinate che indicano il generico macro-blocco sotto processamento. Il macro-blocco (0, 0) è considerato il macro-blocco nell’angolo in basso a sinistra del buffer di frame (ad esempio, lo schermo di visualizzazione 30). I macro-blocchi (i, 0) rientrano interamente nella riga inferiore composta da M linee orizzontali del buffer di frame, mentre i macroblocchi (0, j) indicano la colonna più a sinistra composta dalle prime N linee verticali del buffer di frame 30.

In aggiunta, una volta terminato il processamento di un macro-blocco corrente, il secondo modulo di processamento 250 è configurato per fornire i dati relativi al processamento del macro-blocco, tramite il processore di frammenti 270 ed il modulo di memoria di macro-blocco 280, ad uno o più buffer di frame esterni alla pipeline grafica 200 (ad esempio, buffer di schermo 30, buffer di alpha mask, e così via).

Come si può notare lo scopo dell’invenzione è pienamente raggiunto in quanto la pipeline grafica 200 presenta diversi aspetti vantaggiosi.

In particolare, il posizionamento del modulo di rasterizzazione 230 a monte del primo 240 e secondo 250 modulo di processamento consente alla pipeline grafica 200 di processare primitive di tipo span suddividendole in primitive di tipo sotto-span associabili a porzioni fisse (macro-blocchi) dello schermo di visualizzazione. Il fatto che ciascun sotto-span, per definizione, non risulta mai più grande di un singolo macro-blocco è vantaggiosamente possibile implementare una riduzione del fattore di sovra-scrittura (in inglese, overdraw reduction factor) in quanto risulta più semplice implementare l’algoritmo di scarto o culling su entità così ridotte.

Ancora, il suddetto ordine dei moduli della pipeline grafica 200 comporta inoltre il vantaggio che il contesto di scena da immagazzinare nel buffer di scena è in realtà un sotto-contesto destinato al solo processore di frammenti e pertanto più compatto rispetto al contesto di scena completo destinato a tutta la pipeline grafica. In questo modo è possibile ottenere una riduzione della banda di lettura/scrittura del buffer di scena.

Inoltre, il processamento di un macro-blocco alla volta consente vantaggiosamente di mantenere la larghezza di banda confinata all’interno della pipeline grafica 200 ed in un modulo di memoria interno 280 che rappresenta il macro-blocco.

In aggiunta, il fatto che le primitive (span) in uscita dal modulo di rasterizzazione 230 vengano associate ai macro-blocchi comporta, vantaggiosamente, nessuna particolare operazione di riconfigurazione o cambiamento (hardware o software) del modulo di rasterizzazione stesso.

Ancora, la caratteristica tecnica relativa al rappresentazione compatta dei dati (contesto e primitive di tipo span) secondo un’organizzazione a liste di visualizzazione ciascuna associata ad un macro-blocco dello schermo consente vantaggiosamente di risparmiare banda interna di scrittura (traffico da primo modulo di processamento (binner) a buffer di scena) e lettura (traffico da buffer di scena a secondo modulo di processamento (parser)).

Inoltre, l’implementazione di un algoritmo di scarto o culling su primitive di tipo span consente, vantaggiosamente, di aumentare l’efficienza del test di scarto, di ridurre il numero effettivo di span da renderizzare e diminuire il più possibile, da un punto di vista computazionale, i tempi di processamento della pipeline grafica e la banda di scrittura/lettura da buffer sia interni (ad esempio, la memoria dedicata al macro-blocco) sia esterni (ad esempio il buffer di frame) alla pipeline grafica.

Alle forme di realizzazione del dispositivo sopra descritte, un tecnico del ramo, per soddisfare esigenze contingenti, potrà apportare modifiche, adattamenti e sostituzioni di elementi con altri funzionalmente equivalenti, senza uscire dall'ambito delle seguenti rivendicazioni. Ognuna delle caratteristiche descritte come appartenente ad una possibile forma di realizzazione può essere realizzata indipendentemente dalle altre forme di realizzazione descritte.

Claims (23)

1. RIVENDICAZIONI 1. Un modulo grafico (500) per la renderizzazione di una scena bidimensionale su uno schermo di visualizzazione (30) comprendente una pipeline grafica (200) di tipo sort-middle, detta pipeline grafica (200) comprendendo: - un primo modulo di processamento (240) configurato per suddividere una primitiva d’ingresso di tipo span (s) ricevuta da un modulo di rasterizzazione (230) in primitive di tipo sotto-span (cs) da associare a rispettivi macro-blocchi (M1-M7) corrispondenti a porzioni dello schermo (30) ed immagazzinare dette primitive di tipo sotto-span (cs) in un buffer di scena (260); - un secondo modulo di processamento (250) configurato per ricostruire a partire dalle primitive di tipo sotto-span (cs) la primitiva d’ingresso di tipo span (s), il secondo modulo di processamento (250) essendo inoltre predisposto per implementare un’operazione di scarto di primitive di tipo sottospan (s) di tipo occluso.
2. 2. Modulo grafico (500) secondo la rivendicazione 1, in cui il primo modulo di processamento (240) è configurato per organizzare le primitive di tipo sotto-span (cs) immagazzinate nel buffer di scena (260) secondo una struttura dati di tipo lista (LST).
3. 3. Modulo grafico (500) secondo la rivendicazione 2, in cui la struttura dati di tipo lista (LST) comprende una pluralità di array di liste di visualizzazione (LST) ciascuna lista di visualizzazione (DL) ed un array di puntatori di liste di visualizzazione (DLH).
4. 4. Modulo grafico (500) secondo la rivendicazione 3, in cui ciascuna lista di visualizzazione della pluralità di liste di visualizzazione (DL) comprende porzioni di liste di visualizzazione rappresentative del buffer di scena (260) fra loro concatenate.
5. 5. Modulo grafico (500) secondo la rivendicazione 4, in cui ciascun elemento dell’array di puntatori di liste di visualizzazione (DLH) è rappresentativo di un indirizzo di una porzione del buffer di scena (260) in cui è allocata la prima porzione di ciascuna lista di visualizzazione.
6. 6. Modulo grafico (500) secondo la rivendicazione 5, in cui ciascuna porzione della lista di visualizzazione comprende una pluralità di elementi di lista di visualizzazione (DLE) ed un puntatore (NC) alla porzione di lista di visualizzazione successiva.
7. 7. Modulo grafico (500) secondo la rivendicazione 1, in cui il primo modulo di processamento (240) risulta configurato per ricevere inoltre un’informazione rappresentativa di un sotto-contesto della scena da renderizzare ed immagazzinare detta informazione nel buffer di scena (260).
8. 8. Modulo grafico (500) secondo la rivendicazione 7, in cui il primo modulo di processamento (240) comprende un primo buffer di memoria di scrittura locale (241) in cui immagazzinare localmente il sotto-contesto di scena prima di trasferirlo al buffer di scena (260).
9. 9. Modulo grafico (500) secondo la rivendicazione 8, in cui il primo modulo di processamento (240) comprende inoltre un registro interno in cui immagazzinare l’indirizzo di memoria rappresentativo dell’area del buffer di scena (260) in cui è immagazzinato il sotto-contesto.
10. 10. Modulo grafico (500) secondo la rivendicazione 9, in cui il primo modulo di processamento (240) è configurato per immagazzinare l’informazione relativa al sotto-contesto nella lista di visualizzazione (LST) del rispettivo macro-blocco.
11. 11. Modulo grafico (500) secondo la rivendicazione 1, in cui il primo modulo di processamento (240) è predisposto inoltre per implementare un’operazione di marcamento di primitive di tipo span qualificate come occluse.
12. 12. Modulo grafico (250) secondo la rivendicazione 1, in cui il secondo modulo di processamento (250) comprende un secondo buffer di memoria locale (251) per immagazzinare una lista di visualizzazione associata ad un macro-blocco in processamento.
13. 13. Modulo grafico (500) secondo la rivendicazione 1, in cui il secondo modulo di processamento (250) comprende inoltre un buffer locale di bit di maschera (252) per controllare se la primitiva d’ingresso di tipo span (s) risulta occlusa o meno.
14. 14. Modulo grafico (500) secondo la rivendicazione 13, in cui detto buffer locale di bit di maschera (252) ha dimensione pari a quella di un macro-blocco.
15. 15. Modulo grafico (500) secondo la rivendicazione 2, in cui il secondo modulo di processamento (250) risulta configurato per processare la struttura dati di tipo lista (LST) relativa ad un singolo macroblocco secondo un ordine di processamento che inizia dall’ultimo elemento di lista di visualizzazione immagazzinato nel buffer di scena (260) dal primo modulo di processamento (240) e termina con il primo elemento di lista di visualizzazione immagazzinato.
16. 16. Modulo grafico (500) secondo la rivendicazione 15, in cui la pipeline grafica (200) comprende inoltre un processore di frammenti (270) configurato per ricevere le primitiva di tipo span (s) ricostruita dal secondo modulo di processamento (250).
17. 17. Modulo grafico (500) secondo la rivendicazione 16, in cui detta pipeline grafica (200) comprende inoltre un modulo di memoria di macro-blocco (280) per immagazzinare informazioni relative al macroblocco in processamento.
18. 18. Modulo grafico (500) secondo la rivendicazione 1, comprendente inoltre un modulo pilota (210) ed una pipeline di filtraggio (300), il modulo pilota (210) essendo configurato per ricevere istruzioni da un’applicazione grafica e fornire rispettive informazioni alla pipeline grafica di tipo sortmiddle (200) ed alla pipeline di filtraggio (300).
19. 19. Modulo grafico (500) secondo la rivendicazione 18, in cui la pipeline grafica (200) comprende inoltre uno stadio di processamento di percorso (220) per ricevere dal modulo pilota (230) un’informazione di tipo percorso (P) e fornire al modulo di rasterizzazione (230) un’informazione di tipo percorso semplificato (P’, P”).
20. 20. Sistema grafico (500) comprendente: - un’unità di processamento (40); - un modulo di memoria (50) operativamente associato a detto modulo di memoria (50); - un modulo grafico (500) operativamente associato a detta unità di processamento per la renderizzazione di una scena bidimensionale su uno schermo di visualizzazione (30), detto modulo grafico (500) essendo in accordo ad una delle rivendicazioni precedenti.
21. 21. Sistema grafico (100) secondo la rivendicazione 20, appartenente al gruppo comprendente: set top box HDTV, telefono mobile, palmare PDA, ricevitore digitale terrestre, lettore DVIX, lettore MP3), personal computer), console di gioco PS3.
22. 22. Metodo di renderizzazione di una scena bidimensionale su uno schermo di visualizzazione (30), comprendente fasi di: - suddividere, tramite un primo modulo di processamento (240), una primitiva d’ingresso di tipo span (s) ricevuta da un modulo di rasterizzazione (230) in primitive di tipo sotto-span (cs) da associare a rispettivi macro-blocchi (M1-M7) corrispondenti a porzioni dello schermo (30); - immagazzinare le primitive di tipo sotto-span (cs) in un buffer di scena (260); - ricostruire, tramite un secondo modulo di processamento (250), la primitiva d’ingresso di tipo span (s) a partire dalle primitive di tipo sotto-span (cs); - implementare, tramite il secondo modulo di processamento (250), un’operazione di scarto di primitive di tipo span (s) di tipo occluso.
23. 23. Metodo secondo la rivendicazione 22, in cui la fase di immagazzinare le primitive di tipo sotto-span (cs) comprende la fase di implementare, mediante il primo modulo di processamento (240), un’operazione di marcamento di primitive di tipo span qualificate come occluse.