Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!exodus!gday!maslen From: maslen@eng.sun.com (Thomas Maslen) Newsgroups: comp.arch Subject: Re: Intel graphics chip Keywords: Intel, 586, windows, 82786 Message-ID: Date: 21 Dec 90 06:44:50 GMT References: <1990Dec19.115110.15070@ncsuvx.ncsu.edu> <3070@crdos1.crd.ge.COM> <1990Dec19.154145.10137@ux1.cso.uiuc.edu> <1990Dec20.194956.21974@rice.edu> Sender: news@exodus.Eng.Sun.COM Lines: 162 [ I assume we're all talking about the same chip, the 82786. So far only Kevin Darling and Mark Hall have referred to it by name. ] foo@titan.rice.edu (Mark Hall) writes: >In article <1990Dec19.154145.10137@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes: >)I may be -- probably am -- all wet, but I thought that the Intel and TI >)graphics chips were enitrely different bests: the TI chip was a programmable >)device for drawing graphics primitives onto a frame bufffer while the Intel >)one was, as has been described earlier in this thread, a device for >)manipulating "windows" from asveral parts of a frame buffer onto an >)actual screen. >) >)Anybody really know? Can you layer one onto the other? The 82786 does, or attempts to do, all sorts of things, including the "windows" bit and a fair number of drawing primitives as well. Given this, among other things, I would have thought it odd to combine it with a 34010, but Kevin Darling says that a company called Number Nine has done it. I've never looked at a 34010, so I'll hypothesize wildly that it does a better job on the drawing primitives and maybe on programmability. > I should probably sit quietly by, but that would be out of character 8^) Likewise. I bit my tongue for the first few messages, but now I'm going to be rude about this chip. > I wrote a large chunk of the demo software for the initial trade show > showing the Intel 82786 (Comdex in Las Vegas, 1987? memory is failing). > I have not looked at the chip since then. It does do some graphics > drawing, like drawing lines. It also, as has been noted here, manage > windows in hardware. > IMHO, the 82786 is severely limited in that it is not programmable. Clarification: you can give it lists of commands, DMA'ed out of the memory it manages. I think there is even a stack and call/return commands (can anyone confirm this? It's six months since I saw the manual, and I've been trying to forget it), but I don't remember any conditional transfer instructions -- it could hardly be accused of having a general instruction set. Given that the command lists and stack may live in the same memory space that it manipulates, I occasionally fantasized about using bitblt operations on the code or stack to implement a Turing machine or otherwise construct a more general, if hopelessly inefficient, instruction set. If this part of memory were displayed on the screen it'd be even more fun. > For instance, it did not do polygon filling. To fill polygons, I wrote > a routine to find the interior of a polygon on a scanline by scanline > basis (on the x86). The 82786 would draw the horizontal lines. The > overhead of passing the filling info to the 82786 made polygon-filling > less than spectacular. The handshake for command lists between the 82786 and main-processor software is pretty poor. You write a command list (terminated by a halt instruction) into memory, write a pointer (really a jump instruction) into three of the 82786 registers, and away it goes. You find out when it's done either by polling a bit in an 82786 register or, presumably, by fielding an interrupt (not useful to me; I was meant to be writing user-level Unix code). While it's running you can write more command lists somewhere else in memory, but there's no way of saying "when you're done with that one, start on this one" and there's no way (or maybe it just wasn't documented) to determine how far it's progressed through the commands you gave it. Consequently the main processor spends a lot of time synchronizing with the 786, and for short drawing operations you're better off doing them yourself. I've seen much better (i.e. more efficient for software) implementations of what I think of as ring-buffer protocols in some ethernet controllers and in the display controller that DEC SRC built for their Firefly machines. > I WAS very inpressed with the windowing support, though. Each to his own. One's impression of the chip probably depends a lot on the use to which one is trying to put it (duh), and Mark's application may have suited it better than mine. Me, I was trying to do an X11R4 port to a 386 box running Mach 2.5 (i.e. Berkeley Unix, as far as I was concerned) and the Bell Technologies Blit card, which contains the 82786 and some amount (1MB? 4MB?) of RAM, and the server was meant to run as a user process with minimal driver code in the kernel. The "windowing support" is a list-of-lists. Each entry in the top-level list specifies: - the number of rows (scanlines) to which it applies, - a second-level list, - sundry other stuff I've forgotten. Each entry in the second-level list specifies: - the number of horizontal pixels to which it applies, - the starting address, stride (address offset between adjacent rows), pixel depth (1 to 8 bits) and sundry other properties of the bitmap that should be displayed in this block. The degenerate case, of course, is a single entry at both levels with nrows and ncols defined so that the whole screen uses one bitmap. As I believe someone noted, each second-level list is limited to 16 entries. The ability to mix bitmaps of different depths is cute, but has all sorts of restrictions if you're using VRAMS or one of the hi-res modes on the chip. Somewhere in there is a notion of zooming selected windows, but I don't remember much about it. The chip also provides cursor support, with X-Y coordinates specified in a pair of 82786 registers, but the choices are - cross-hairs which extend over the whole screen, or - a 16x16 (I believe), single-colour pattern. Both the windowing support and the cursor support are probably good for something, but they're a poor match for X11. By the time you're done calculating window overlaps and worrying about the n > 16 case (eight windows properly aranged on one row should be enough to trigger this), not to mention doing memory-allocation in the 82786 memory for all these windows, it's not clear to me how much the windowing support helps. X11 is most happy with an arbitrary-size, two-colour cursor (i.e. within the bounding rectangle of the cursor each pixel may be black, white, or whatever is underneath the cursor). It can live with 16x16, and it can live with a single colour, and it does both on the DEC QVSS display, but it's not pretty (the QVSS cursor changes from black to white as you drag it around. I believe DEC fixed this in the SM framebuffer). I ended up using the machine-independent cursor code in the X11R4 distribution, which is amazingly clean and general and so not amazingly efficient. Another irritation... the chip thinks in 16-bit words, and its display bit-order within a word is big-endian. This doesn't sit too well with a 386 processor which is little-endian. In fact the only reason that I didn't end up completely losing my mind was that the X11 folks had done a great job of ifdef'ing their code for various bit-orders and word-sizes, and the IBM X11 folks had added an extra level of support that they needed for the VGA (8-bit big-endian, I believe?). Still found a few holes in the X11R4 sources, but not many. I would have thought that, given that everything else on the chip was meant to be programmable, it would have been ridiculously easy to make the bit-order programmable, but then I'm ignorant of the hardware complexities. Incidentally, what's the bit-order of the 34010? I thought I'd heard that it is big-endian, but may be deluded. More griping... there are at least three sorts of 82786 "registers". Some are accessed directly by main-processor writes to specific addresses. I believe, but may be misremembering, that some are written indirectly, i.e. the main processor writes a number into a "register selector" register, then writes the data in a "register value" register. Some pretty fancy parameter blocks are read and written by DMA. Finally, some registers are read and written by 82786 instructions. Overall, the chip felt like something I might have designed if I'd been let loose on an unsuspecting hardware world. Basically good ideas, but implemented sufficiently badly that you couldn't really use them. At least one obscure and annoying bug, too (a bit in the top-level window list that I shouldn't have had to set, but if I didn't then the display was comprehensively curdled). One could be forgiven for thinking that the chip was done by an isolated group who had never heard of the term "design review", or maybe even the term "design". If Intel has delusions of putting windowing support in the 586, they should use the 82786 as a counterexample rather than as a paradigm. There, I feel better now. Check your Mercury News tomorrow to see whether it says "Sun employee beaten up while riding home". Seriously, if you're interested in the chip, get a copy of the programmer's manual, read it thoroughly, and decide whether it's right for your application. The obligatory disclaimers: These opinions are quite definitely mine, not those of Sun Microsystems. My experience with the 82786 occurred in a previous job at another company. Thomas Maslen maslen@eng.sun.com