ITMI20082342A1 - Modulo di renderizzazione per grafica a due dimensioni, preferibilmente basato su primitive di tipo bordo attivo - Google Patents

Description

“MODULO DI RENDERIZZAZIONE PER GRAFICA A DUE DIMENSIONI, PREFERIBILMENTE BASATO SU PRIMITIVE DI TIPO BORDO ATTIVO”

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 dei dati 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 viene raggiunto 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 13.

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

Forma oggetto della presente invenzione anche un metodo di renderizzazione come definito nella rivendicazione 16.

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 1 illustra schematicamente un sistema grafico in accordo con un esempio di realizzazione; - la figura 2 illustra schematicamente un modulo grafico secondo un esempio dell’invenzione;

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

- la figura 4 illustra 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, e

- la figura 5 illustra schematicamente un esempio di organizzazione di un buffer di memoria interno alla 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 40 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 80 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 40.

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 40. 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 60.

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 (renderizzazione) della scena sullo schermo sulla base dei dati precedentemente elaborati e memorizzati. 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, ordine 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/o 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, in base alla specifica semantica di ogni particolare comando, 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 implicito di partenza (ad esempio di coordinate X0, Y0) 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 implicito di partenza (X0, Y0) 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 affine e/o 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 (contrazione dall’inglese picture element) adiacenti ciascuno avente un determinato colore. L’immagine bitmap è tale da essere ricevuta in ingresso dalla pipeline grafica 2D 200 ed essere disegnata (renderizzata) direttamente sullo schermo in seguito ad un’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 P 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 primo modulo di rasterizzazione 230a (front-end rasterizer), un primo modulo di processamento 240 (binner o raccoglitore), un secondo modulo di processamento 250 (parser o analizzatore), un buffer di memoria interna 260 (scene buffer), un secondo modulo di processamento 230b (back-end rasterizer), un processore di frammenti 270 (fragment processor), un modulo di memoria di macro-blocco 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 primo modulo di rasterizzazione 230a un path semplificato 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 semplificato 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 d’uscita P’ è comunemente chiamato anche bordo o edge, in seguito anche primitiva di tipo bordo.

Come noto al tecnico del settore, con primitiva di tipo bordo o edge s’intende un segmento rettilineo orientato in un predeterminato verso tra un punto di inizio ed un punto di fine. Il predeterminato verso di un bordo è stabilito dal confronto tra le coordinate Y del punto di inizio e del punto di fine del bordo. Se la coordinata Y del punto di inizio è minore della coordinata Y del punto di fine, il segmento sarà orientato in un primo verso (ad esempio verso l’alto, direzione UP); se la coordinata Y del punto di inizio è uguale o maggiore rispetto alla coordinata Y del punto di fine il segmento sarà orientato in un secondo verso (ad esempio verso il basso, direzione DOWN).

Con riferimento ancora allo stadio di processamento di percorso 220, si noti che esso risulta a sua volta, preferibilmente, una micropipeline 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 o bordo 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 semplificato 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 primo modulo di rasterizzazione 230a il path d’uscita semplificato (o primitiva di tipo bordo) P’ come generato dal modulo di tessellizzazione in quanto l’operazione di riempimento di un path è globalmente eseguita concatenando opportunamente le operazioni sia del primo modulo di rasterizzazione 230a sia del secondo modulo di rasterizzazione 230b. 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 primo modulo di rasterizzazione 230a 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 primo modulo di rasterizzazione 230a il tipo di path semplificato d’uscita (P’ o P”) in un formato compatibile, o comunque riconoscibile, dal primo modulo di rasterizzazione 230a. La scelta del tipo di path semplificato in uscita (P’ o P”) dipende in ogni caso dallo stato della pipeline grafica 200.

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 primo modulo di rasterizzazione 230a è un modulo di rasterizzazione 2D AET FrontEnd (Active Edge Table Rasteriser FrontEnd), di per sé noto, che risulta operativamente associato allo stadio di processamento di percorso 220 e configurato per ricevere da esso una primitiva di tipo bordo (path d’uscita semplificato P’ o l’ulteriore path d’uscita P”) e fornire in uscita una primitiva di tipo bordo attivo AE (bordo o edge in coordinate superficie o schermo).

Si ribadisce che il path semplificato (P’ o P”) in ingresso al primo modulo di rasterizzazione 230a, risulta un segmento rettilineo (bordo o edge) orientato sulla schermo definibile da un primo punto, da un secondo punto e da un’informazione rappresentativa del confronto tra le coordinate Y sullo schermo del primo e del secondo punto. Tale informazione indica il verso di orientamento del segmento che può essere verso l’alto o verso il basso (informazione di up/down).

Per primitiva di tipo bordo attivo (in inglese, active edge) s’intende una primitiva di tipo bordo fornita in uscita dal primo modulo di rasterizzazione 230a come risultato di una classificazione delle primitive di tipo bordo in ingresso al primo modulo di rasterizzazione 230a sulla base della regione spaziale che ogni singola primitiva di tipo bordo in ingresso va ad interessare sullo schermo.

Come verrà descritto nel seguito, la suddetta classificazione viene implementata seguendo due principi.

Il primo principio si basa su un criterio di scansione per linee orizzontali dello schermo (in inglese, scan lines). Secondo questo criterio ogni primitiva di tipo bordo (edge) appartenente al path semplificato P’ (o P”) in ingresso al primo modulo di rasterizzazione 230a è classificato come primitiva di tipo bordo attivo (rispettivamente ad una linea di scansione orizzontale i-esima) se detta primitiva di tipo bordo (edge) interseca in un punto la linea di scansione stessa.

A titolo di esempio, dato uno schermo di visualizzazione (W x H) dove W rappresenta il numero di colonne ed H rappresenta il numero di righe, il numero di linee di scansione risulta pari ad H. In particolare, ogni linea di scansione i-esima risulta passante per ciascun centro dei pixel adiacenti su tale linea.

Il secondo principio di classificazione si basa su secondo criterio di valutazione che, in accordo all’esempio dell’invenzione si basa su una associazione di tipo macro-blocco descritta nel dettaglio in seguito.

Con riferimento ora alla figura 4, viene ora descritto un esempio di insieme di primitive di tipo bordo o edge attivo AE (individuate secondo una associazione di tipo macro blocco) orientati su uno schermo SCH (ad esempio, il display 30 dell’apparato televisivo 20). L’insieme di primitive di tipo bordo attivo AE concorrono alla definizione del contorno del path d’ingresso P proveniente dal modulo driver 210.

Nell’esempio di figura 4, il path d’ingresso P è una figura a stella STL e l’insieme di primitive di tipo bordo o edge attivo con cui è approssimata la figura a stella STL comprende un primo bordo attivo E1, un secondo bordo attivo E2, un terzo bordo attivo E3, un quarto bordo attivo E4 ed un quinto bordo attivo E5.

Il primo bordo attivo E1 è definito da un punto di inizio P1, un punto di fine P1’ ed una direzione verso l’alto (UP); il secondo bordo attivo E2 è definito da un punto di inizio P2, un punto di fine P2’ ed una direzione orizzontale (DOWN per la convenzione descritta precedentemente); il terzo bordo attivo è definito da un punto di inizio P3, un punto di fine P3’ ed una direzione verso il basso (DOWN); il quarto bordo attivo E4 è definito da un punto di inizio P4, un punto di fine P4’ ed una direzione verso il basso (DOWN); il quinto bordo attivo E5 è definito da un punto di inizio P5, un punto di fine P5’ ed una direzione verso l’alto (UP).

Si fa presente che la direziona sopra indicata di ciascun bordo attivo è ottenuta, come già detto in precedenza, dal confronto tra le coordinate Y del punto di inizio ed il punto di fine.

Facendo nuovamente riferimento alla figura 3, il primo modulo di processamento (binner) 240 è configurato per ricevere in ingresso la primitiva di tipo bordo attivo AE ricevuta dal primo modulo di rasterizzazione 230a ed associare essa ad un macroblocco rappresentativo dello schermo di visualizzazione SCH ed appartenente all’insieme di macro-blocchi in cui è contenuta la primitiva di tipo path da renderizzare sullo schermo.

Si fa presente che nell’esempio della figura 4 la porzione di schermo di visualizzazione SCH mostrata comprende un insieme di 15 macro-blocchi mentre la figura a stella STL da renderizzare occupa un sotto-insieme di 9 macro-blocchi.

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 primitive di tipo bordo attivo AE ed alla dimensione di un macro-blocco, il primo modulo di processamento 240 è altresì configurato per ricevere un’informazione relativa al solo sotto-contesto (sub-contest) del processore di frammenti 270 e del secondo modulo di rasterizzazione 230b posto a valle del secondo modulo di processamento (parser) 250.

Il primo modulo di processamento 240 risulta configurato per immagazzinare nel buffer di memoria 260 le informazioni relative alle primitive di tipo bordo attivo 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) di dimensione pari alla dimensione fissa, nota a priori, di ciascuna porzione di memoria (chunk).

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. 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 secondo modulo di processamento 230b (ad esempio, regola di riempimento, “fill rule”) ed al processore di frammenti 270.

Inoltre, si consideri che dal momento che uno stesso sotto-contesto è condivisibile da differenti primitive di tipo bordo attivo, esso è immagazzinato nel buffer di scena 260 solo una volta ed associato a ciascuna primitiva di tipo bordo attivo AE 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, ma presenta una dimensione massima definita dalle specifiche dello standard openVG.

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 ciascuna primitiva di tipo bordo attivo (active edge) AE che riceverà dal primo modulo di rasterizzazione 230a e che successivamente sarà sottoposto al secondo modulo di rasterizzazione 230b.

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

Si ribadisce che il primo modulo di processamento 240 è configurato per ricevere dal primo modulo di rasterizzazione 230a le primitive d’ingresso di tipo bordo attivo da esso generate in accordo con la primitiva di tipo path P da renderizzare. In particolare, tali primitive d’ingresso di tipo bordo attivo sono rappresentative del contorno della primitiva di tipo path da renderizzare (nella figura 4, la figura a stella STL) in accordo alla regione dello schermo in cui la primitiva di tipo path è mappata.

Nell’esempio della figura 4, la primitiva di tipo path (stella STL) risulta mappata all’interno di una regione di limite di percorso RL (in inglese, path bounding box) rappresentata con una linea tratteggiata. Ai fini della presente descrizione, per regione di confine di percorso s’intende la minima regione dello schermo che include completamente la primitiva di tipo path da renderizzare.

Si noti che il primo modulo di processamento 240 è configurato per inserire, per ciascun macroblocco dello schermo di visualizzazione che interseca la regione di limite RL, un puntatore (“handle”) ad un’area di memoria in cui è immagazzinato il contesto nella lista di visualizzazione di ciascun macroblocco.

Contestualmente, il primo modulo di processamento 240 è configurato per inserire nella lista di visualizzazione di ciascun macro-blocco un puntatore (“handle”) ad un’altra area di memoria in cui è immagazzinato un set di informazioni di primitive di bordo attivo (“edge data set handle”). Si fa presente che con set di informazioni di primitive di bordo attivo (“edge data set”) s’intende l’insieme di primitive di bordo che definiscono il contorno della primitiva di tipo path P da renderizzare sullo schermo SCH classificate secondo la classificazione basata sul criterio di scansione per linee orizzontali dello schermo (scan lines) descritta in precedenza.

Facendo nuovamente riferimento alla figura 3, il secondo modulo di processamento 250 risulta operativamente associato al buffer di scena 260 per caricare dal buffer di memoria 260 la primitiva di ingresso di tipo bordo attivo AE e fornire detta primitiva di tipo bordo attivo AE al secondo modulo di rasterizzazione 230b (AET Rasterizer back-end).

Si noti inoltre che, come illustrato simbolicamente anche nella figura 3, 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 bordo attivo come ricevuti dal primo modulo di rasterizzazione 230a ed immagazzinarli in una rappresentazione compatta (primitive di tipo bordo attivo 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, il secondo modulo di processamento 250 è predisposto per leggere i dati immagazzinati nel buffer di scena 260 e, procedendo secondo un predeterminato ordine dei macro-blocchi, a reimpostare il sotto-contesto locale del secondo modulo di rasterizzazione 230b e del processore di frammenti 270 e individuare il set di informazioni di primitive di bordo attivo (“edge data set”) immagazzinati in esso.

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, detto anche comando SHOW (mostra). Contestualmente al comando di SHOW possono essere forniti ulteriori comandi, previsto dallo standard OpenVG, che indicano di procedere con lo svuotamento (in inglese, flush o finish) 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 secondo modulo di rasterizzazione 230b, il processore di frammenti 270, il modulo di memoria di macro-blocco 280) 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) 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.

Successivamente al caricamento del contesto corrente, il secondo modulo di processamento 250 è configurato per leggere uno o più elementi di lista di visualizzazione immagazzinati nel buffer di memoria 260. In particolare, il secondo modulo di processamento 250 è configurato per acquisire dal buffer di memoria 260 tutte le informazioni relative alle primitive di tipo bordo attivo che appartengono alla primitiva di tipo path P da renderizzare. Inoltre il secondo modulo di processamento 250 risulta altresì configurato per controllare se la primitiva di tipo bordo attivo interseca (anche solo parzialmente) la singola regione di macro-blocco ed, in caso positivo, inviare la stessa primitiva di tipo bordo attivo al secondo blocco di rasterizzazione 230b per ulteriori processamenti.

Una volta che tutte le primitive di tipo bordo attivo di una primitiva di tipo path (che intersecano la regione di macro-blocco corrente) vengono correttamente letti dal buffer di memoria da parte del secondo modulo di processamento 250, esso risulta configurato per inviare le primitive di tipo bordo attivo al secondo blocco di rasterizzazione 230b (in accordo a regole di riempimento associate).

Il secondo modulo di rasterizzazione 230b risulta a sua volta predisposto per trasformare le primitive di tipo bordo attivo AE in primitive di tipo span da fornire al processore di frammenti 270.

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 alla primitiva di tipo path definita dalle primitive di tipo bordo attivo AE proveniente dal secondo modulo di rasterizzazione 230b. 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 alla primitiva di tipo path definita dalle primitive di tipo bordo attivo. Il valore di copertura o coverage è definito come un numero compreso tra 0 e 1.

Un frammento incluso completamente all’interno della primitiva di tipo 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 della primitiva di tipo path ha, rispetto ad esso, sovrapposizione parziale e pertanto percentuale di copertura inferiore al 100 % (per definizione, valore di copertura < 1).

Gli span generabili dal modulo di rasterizzazione 230b possono essere di due tipi: span interno (internal span) ossia insieme di frammenti adiacenti fra loro interamente sovrapposti alla primitiva di tipo path (valore di copertura pari a 1); span di bordo (border span) ossia insieme di frammenti adiacenti parzialmente sovrapposti alla primitiva di tipo path (stesso valore di copertura, in questo caso minore di 1).

Il secondo modulo di rasterizzazione 230b è configurato per decidere, in base al set di regole di riempimento, quali frammenti sono all’interno o all’esterno di un particolare contorno del path da renderizzare. Per ciascun frammento prodotto, un particolare valore di copertura è stabilito.

Una volta che il processamento della lista di visualizzazione per il corrente macro-blocco sotto processamento è terminata, il contenuto dei macroblocchi necessita di essere trasferito in un buffer di frame esterno (ed eventualmente in un alpha mask buffer se abilitato).

Nel caso in cui un algoritmo di anti-aliasing basato su super campionamento è impiegato, la memoria interna di macro-blocco è considerata a super risoluzione di campionamento. Pertanto, un filtro a basso campionamento (ottenuto calcolando la media dei colori dei sotto pixel) è adottato nel caso in cui i dati vengano immagazzinati in un buffer di frame esterno.

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.

Infatti, l’ordine dei moduli o blocchi che compongono la pipeline grafica 200 comporta il vantaggio che il contesto di scena da immagazzinare nel buffer di scena è in realtà un sotto-contesto destinato al secondo modulo di rasterizzazione 230b ed al processore di frammenti 270 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 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 bordo attivo) 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)).

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 (17)

1. RIVENDICAZIONI 1. 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 rasterizzazione (230a) configurato per trasformare una primitiva d’ingresso di tipo bordo (P’, P”) ricevuta da un modulo di processamento di percorso (220) in una primitiva di tipo bordo attivo (AE); - un primo modulo di processamento (240) configurato per associare detta primitiva di tipo bordo attivo (AE) a rispettivi macro-blocchi corrispondenti a porzioni dello schermo (30) ed immagazzinare detta primitiva di tipo bordo attivo (AE) in un buffer di scena (260); - un secondo modulo di processamento (250) configurato per leggere detto buffer di memoria (260) e fornire detta primitiva di tipo bordo attivo (AE) ad un secondo modulo di rasterizzazione (230b).
2. 2. Modulo grafico (500) secondo la rivendicazione 1, in cui il primo modulo di processamento (240) è configurato per organizzare le primitive di tipo bordo attivo (AE) 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 liste 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 (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.
12. 12. Modulo grafico (500) secondo la rivendicazione 1, in cui il secondo modulo di rasterizzazione (230b) risulta configurato per generare, sulla base delle primitive di tipo bordo attivo (AE) ricevute dal secondo modulo di processamento (250), una primitiva di tipo span (S), detta pipeline grafica (200) comprendendo inoltre un processore di frammenti (270) configurato per ricevere detta primitiva di tipo span (S).
13. 13. Modulo grafico (500) secondo la rivendicazione 11, in cui detta pipeline grafica (200) comprende inoltre un modulo di memoria di macro-blocco (280) per immagazzinare informazioni relative al macroblocco in processamento.
14. 14. Modulo grafico (500) secondo la rivendicazione 1, in cui la pipeline grafica (200) comprende inoltre un modulo pilota (210) per fornire una primitiva di tipo percorso (P) allo stadio di processamento percorso (220), detto stadio di processamento percorso (220) essendo configurato per trasformare la primitiva di tipo percorso (P) nella primitiva di tipo percorso semplificato (P’, P”).
15. 15. 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.
16. 16. Sistema grafico (100) secondo la rivendicazione 15, 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.
17. 17. Metodo di renderizzazione di una scena bidimensionale su uno schermo di visualizzazione (30), comprendente fasi di: - trasformare, da parte di un primo modulo di rasterizzazione (230a), una primitiva d’ingresso di tipo bordo (P’, P”) ricevuta da un modulo di processamento di percorso (220) in una primitiva di tipo bordo attivo (AE); - associare, da parte di un primo modulo di processamento (240), detta primitiva di tipo bordo attivo (AE) a rispettivi macro-blocchi corrispondenti a porzioni dello schermo (30); - immagazzinare, da parte di detto primo modulo di processamento (240), detta primitiva di tipo bordo attivo (AE) in un buffer di scena (260); - leggere, da parte di un secondo modulo di processamento (250), detto buffer di memoria (260) per fornire detta primitiva di tipo bordo attivo (AE) ad un secondo modulo di rasterizzazione (230b).