Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!spool.mu.edu!munnari.oz.au!bruce!labtam!graeme From: graeme@labtam.labtam.oz (Graeme Gill) Newsgroups: comp.arch Subject: Re: Bitfield instructions--a good idea? Message-ID: <10408@labtam.labtam.oz> Date: 19 Apr 91 10:19:02 GMT References: <1991Apr15.193425.3436@waikato.ac.nz> Organization: Labtam Australia Pty. Ltd., Melbourne, Australia Lines: 27 In article , spot@CS.CMU.EDU (Scott Draves) writes: > In article <1991Apr18.093804.18183@odin.diku.dk> torbenm@diku.dk (Torben [gidius Mogensen) writes: > > What is (often?) needed in graphics systems is to convert raster > arrays from one number of bits per pixel to another, for example 1 bit > per pixel to two bits per pixel. > > this rarely happens. 1 -> 8 or 1 -> 24 happens on occasion, but i > doubt any of these are significant compared to blitting and rendering. Consider that many applications are written to run on monochrome devices, so they use single level bitmaps and fonts to encode graphic objects. When rendered on a colour device, the 1->8 or 1->24 bit expansion is used a great deal. > when it does happen, you can use look up tables. to do your 1 -> 2 > bits per pixel example, i would use a table of 256 entries, 16 bits > each. In fast hardware the memory bandwidth is the limit. Using lookup tables doubles the number of memory accesses, thereby halving the ultimate speed. Hardware support for 1->power_of_two expansion is a desirable feature in a graphics processor. Graeme Gill Labtam Australia