Il disegno indice è più veloce del disegno non indice

Devo disegnare molti poligoni costituiti da 6 vertici (due triangoli).

Senza coordinate di trama, normali ecc., Entrambi gli approcci generano 72 byte. In futuro avrei sicuramente bisogno anche delle coordinate e delle normali delle trame, il che renderebbe il disegno degli indici meno memoria. Non molto però.

Quindi la mia domanda è: per i VAO con poche sovrapposizioni di vertici, quale approccio è più veloce? Non mi interessa la memoria aggiuntiva consumata dal disegno senza indice, solo la velocità.

Modifica: per chiarire.

Approccio non indicizzato:

float[18] vertices = {
//Triangle 1
1,1,0,
1,0,0,
0,0,0,

//Triangle 2
1,0,0,
0,1,0,
0,0,0,
};

Approccio all'indice:

float[12] vertices = {
1,1,0,
1,0,0,
0,0,0,
0,1,0,
};

int[6] indices = {
//Triangle 1
0,1,2,

//Triangle 2
0,3,2
};

Provo a rispondere alla domanda. Penso che dovresti andare con gli indici, per alcuni motivi:

1) In ogni caso, l'indicizzazione è un'operazione gratuita sul lato GPU, non si prendono penalità lì. (aggiunto) Naturalmente, gli indici sono operazioni di accesso casuale e possono danneggiare le prestazioni della cache di memoria della GPU.

2) L'indicizzazione può consentire alla cache dei vertici della GPU di effettuare quelle poche ottimizzazioni per i vertici sovrapposti.

3) Ingombro di memoria ridotto sul lato GPU molte volte significa prestazioni migliori, poiché la larghezza di banda della memoria è uno dei colli di bottiglia e perché molte volte le operazioni di estrazione (ad esempio 10_10_10_2 -> 4 x float) sono gratuite.

La differenza di velocità probabilmente non è evidente se non ci sono molti vertici sovrapposti in cui è possibile ottenere un miglioramento della velocità. Ma davvero non ho fatti concreti per supportare la mia opinione (per andare con gli indici).

Guarda anche questo:

/programming/17503787/buffers-indexed-or-direct-interlaced-or-separate

Se le posizioni sono sempre le stesse, puoi persino fare a meno di eventuali buffer memorizzando l'array nello shader e usando gl_VertexIDper selezionare il vertice nello shader di vertici.

#version 330 core

const vec3 data[4] = vec3[]
(
//Triangle 1
vec3(1,1,0),
vec3(1,0,0),
vec3(0,0,0),

//Triangle 2
vec3(1,0,0),
vec3(0,1,0),
vec3(0,0,0)
);

void main()
{
  gl_Position = vec4( data[ gl_VertexID ], 1.0);
}

come per tutte le cose da spettacolo, non indovinare, profilalo per scoprirlo.

varierà a seconda dell'hardware e di molti fattori complicati. misurandolo con la profilazione, prenderai in considerazione automagicamente tutte queste cose per te senza che tu ne abbia bisogno.

La mia ipotesi è che l'uso dell'indicizzazione per i vertici sarebbe più lento.

Ho frainteso la domanda originale, ma ecco la risposta per l'indicizzazione del colore. Immagino che le stesse regole si applicherebbero all'indicizzazione dei vertici (senza perdita di precisione), ma è solo una supposizione.

Ma...

• Come regola generale, suggerisco l'indicizzazione.
• L'indicizzazione è più lenta.
• Non indicizzare è più veloce.
• L'indicizzazione è più efficiente in termini di memoria.
• Non indicizzare è meno efficiente della memoria.
• L'indicizzazione perde la precisione del colore.
• La mancata indicizzazione non perde la precisione del colore.

72 byte è così piccolo che probabilmente sarebbe più efficiente la memoria per non indicizzarlo.

Alcune regole pratiche: l'indicizzazione è più efficiente in termini di memoria. L'indicizzazione perde la precisione del colore. Non indicizzare è più veloce.

Questo potrebbe farti desiderare di non usare mai l'indicizzazione, ma il compromesso della memoria è piuttosto significativo per immagini di dimensioni decenti. La precisione del colore è impercettibile.

Il modo in cui funziona l'indicizzazione è che quando si tratta di disegnare un pixel, viene dato un indice e deve cercare il colore in una tabella di dimensioni predeterminate. (Diciamo 256 byte, quindi sei limitato a 256 colori). Quindi disegna quel pixel. Nessuna indicizzazione memorizza direttamente i dati dei pixel, quindi nessun colore limita a 256. Ma in un'immagine 100x100, l'immagine di 400ish byte ora è di 10000 byte.

Disclaimer, sto estraendo questi numeri dal mio cappello.