On Sunday 15 December 2002 02:46, J.A. Magallon wrote: > On 2002.12.14 andre wrote: > >On Saturday 14 December 2002 09:59, Lea Gris wrote: > >> This is a hardware feature not a driver software implementation. 128 > >> bits graphic chips would have much much work addressing odd order of > >> bytes boundary (24bits 3 bytes) in memory even worse this would require > >> one more address line switch and additional logic for the RAMDAC to > >> decode pixels colour at an odd boundary de facto reducing decoding > >> speed. > >> > >> If you only do 2 and 4 byte addressing you can complietely avoid using > >> the lower addres line, transfering data with twice and fourth the > >> bandwidth required by single byte addressing. > > > >I know that seems logical. But if you think about it it isn't. The main > >barrier graphic hardware has is bandwidth and with a simple translation > > you can pack 4 pixels into 3, That is a 33% increase of bandwidth! You > > can claim that that needs extra hardware to be done but you have to > > realise that the hardware is purpose build so it probably has that > > hardware build in. > > You are thinkin on a gpu that does things pixel by pixel, with a 4 byte > word. You just need to drop one byte. > A modern 128 byte wide gpu can (for example) fill 128/4 = 32 pixels with > one memory access. And for any other operation apart from reading, ie, > alpha blend two pixels, will you also build a 3-byte register to multiply > and add ? And if you have 32bit registers, each access for a non trivial > read or write implies a pack-unpack operation...
with a 128 byte wide gpu you could fill 128/3=42pixels. a 30% increase. And this maybe a non trivial operation but it isn't exactly rocketscience either. It could be easy done in one clock cycle and because you know probably which memory you want to read next it will even cost even less. In my opinion they do it.
