Found this in #xorg-devel. Figured it might be useful. Also see "http://www.virtuousgeek.org/exa-driver.txt"
03:29 < Ori> 1) is there any overview of X + DRI + DRM + whatever other parts I'd need to know about to start helping out? 03:30 < Ori> 2) would testing Exa (and X from CVS) on a IBM Thinkpad R40 (1400x1050 screen, 32 mb ATI 7500) be helpful now? 03:30 < Ori> is Exa even usable enough for testing on such a machine? 03:30 < ajax> there's two parts to ex 03:30 < ajax> a 03:30 < ajax> there's a generic acceleration engine, and then some driver-specific hooks 03:31 < ajax> we've got the generic core already, we need people to add support to their favorite drivers 03:32 < ajax> i'd recommend reading http://www.virtuousgeek.org/exa-driver.txt for the API overview as far as what your driver would need to provide 03:33 < Ori> ajax: well, I was hoping for more of a basic overview of the stuff, heh. as I said, I have almost zero knowledge of the specifics of driver writing 03:33 < ajax> and then if you're feeling adventurous, i believe the latest experimental exa patch for radeon that anyone has done is http://people.freedesktop.org/~anholt/radeon-exa-disaster-7.diff 03:33 < ajax> okay, five minute overview time 03:33 < ajax> there are four major drawing APIs that the X server exposes: 03:34 < ajax> core X, Render, GL, and Xv 03:34 < ajax> exa makes the first two go fast 03:34 < ajax> of core X, only two requests see any real use these days: 03:34 < ajax> solid color fills, and blits (block copies) 03:35 < Ori> mm, yeah. that much I know. 03:35 < ajax> Render you can think of as a generalized blit, where you combine the source with the destination according to some math on an alpha channel 03:36 < ajax> the EXA core translates those requests, on the X protocol side, into commands to the driver 03:36 < Ori> mm, what about drawing [filled] curves? I'd guess that it would see a fair bit of use 03:36 < ajax> you'd be wrong ;) 03:37 < ajax> you can either do them as a series of blits or fills on very small rectangles, or as a single big alpha blend (where the part outside of the curve you're drawing is set to transparent) 03:37 < Ori> heh, ok. well, I'm noob =) 03:37 < ajax> but yeah, those three operations are about 99% of the drawing X does 03:37 < ajax> so, exa takes these commands at kind of a high level and splits them into phases 03:38 < Ori> mm. sounds awkward to do curves that way, but I'll take your word that it's better. 03:38 < Ori> mm, and somehow controls the hardware. 03:38 < ajax> looking at my firefox window, for example, i've got three regions filled with solid white: empty doc window, URL bar, and search bar 03:38 < anholt> Ori: actually, the pretty curves you get with cairo are a non-core operation done using small trapezoids. 03:39 < ajax> so EXA would split that up like: setup for white fill, fill in these three rectangles, and then clean up if you need to 03:39 < ajax> my driver's SolidSetup routine would set the foreground paint color to white, set the raster operation to "copy", etc. 03:40 < ajax> my driver's Solid routine would do the work of actually filling those rects in 03:40 < Ori> ajax: "copy"? 03:40 < ajax> Ori: as opposed to AND, OR, XOR, CLEAR, etc. 03:40 * Ori would have expected it to be "FILL" or "CLEAR" 03:41 < ajax> copy meaning copy the foreground color to the destination pixels 03:41 < Ori> yeah.. to me, "copy" sounds like "blit"(right term? move pixels from one place to another, anyway) 03:42 < ajax> (and then my DoneSolid routine would maybe clean up, but most cards don't need it) 03:42 < Ori> cool, seems pretty simple. 03:42 < ajax> well sure. think of it as blitting from a 1x1 source pixel that's offscreen, and repeating it over an area. 03:43 < Ori> now, how about actually interfacing with the hardware? how would one go about that? 03:43 < Ori> (in general, of course) 03:43 < ajax> heh. you just, kinda, do it. 03:43 < ajax> as an example 03:44 < ajax> i'm working on exa for this old card i've got laying around, uses the i128 driver 03:44 < ajax> http://people.freedesktop.org/~ajax/i128-exa-8.patch 03:44 < ajax> so again, let's take solid fill as the example 03:45 < ajax> look in that patch for the i128PrepareSolid function 03:45 < ajax> i have little functions to set the various parameters, just because i think it makes it easier to read 03:46 < ajax> but pretty much every one of those functions is setting exactly one register on the card 03:46 < Ori> mm, cool, sorta makes sense. 03:47 < ajax> one each for: mask, foreground color, top left cliprect corner, bottom right cliprect corner, fill direction, and source and dest x y and pitch 03:47 < ajax> i128 is a pretty primitive card 03:47 < Ori> um.. is there any sorta overview of how a graphics card driver would typically control the card floating around on the net? 03:47 < ajax> what do you mean by "control the card" ? 03:47 < Ori> since I'm not sure esactly what the fill direction, pitch, etc are supposed to do 03:48 < Ori> as I said, I have just about 0 knowledge of writing drivers =/ 03:48 < ajax> think of the graphics chip as a little tiny cpu that you're uploading a program to 03:48 < anholt> ajax: interesting, you don't wait for fifo space to write to the card? 03:48 < ajax> yeah i do, ENG_PIPELINE_READY, but the fifo's only 1 deep... 03:49 < ajax> once you poke the trigger reg it shadows all the parameters into the chip, and you can start modifying again 03:49 < ajax> Ori: okay, so, fill direction. you've got the rectangle you're drawing into, right 03:50 < anholt> that's kind of neat. 03:50 < ajax> you can only fill it in one pixel at a time 03:50 < Ori> mm. so left->right, top->bottom? 03:50 < ajax> so you can start in any of the four corners and go towards the other one 03:50 < ajax> right 03:50 < ajax> s/other/opposite/ 03:51 < ajax> anholt: it seems to be a pretty common model, i think tdfx works the same way, i know rendition does too 03:51 < Ori> ajax: well, is that actually useful to control? I mean, for which cases would you care about fill direction? 03:52 < ajax> Ori: think about scrolling a window 03:52 < anholt> ajax: afaik tdfx is ati or sis-like. you've got a short fifo that all your reg writes go through, so you just make sure you don't write while full, or you'll stall. 03:52 < ajax> where your destination and source for the blit occupy the same space on the window 03:52 < Ori> ah. right, but how would the driver know? 03:52 < ajax> Ori: exa tells it which direction to blit, and we assume exa figured it out by magic 03:53 < Ori> ah. I'm guessing that it's just not in the functions I've looked at then. (hardcoded in i128PrepareSolid(), AFAICT) 03:54 < ajax> yeah, solid fills don't really care about direction 03:54 < ajax> blits do though 03:54 < ajax> PrepareCopy lower down passes real values to SetBlitDirection 03:55 < Ori> ok 03:56 < Ori> and pitch? 03:56 < ajax> say you've got a pixmap in offscreen memory 03:56 < ajax> and it's 100 wide and 200 high 03:56 -!- ssp [firstname.lastname@example.org] has joined #xorg-devel 03:56 < ajax> but it's packed, so the last pixel on the first line is next to the first pixel on the second line 03:57 < Ori> so pitch would be the image width? 03:57 < ajax> right 03:57 < Ori> cool, that's pretty helpful 03:58 < anholt> more specifically, it's the distance from the beginning of one line to the next line. sometimes hardware wants that distance to align to some number, so exa will pad the width out for you and that's the pitch. 03:58 < anholt> (while the width remains the actual number of valid pixels that X uses) 03:58 < Ori> mm. Exa handles the padding, then. 03:58 < ajax> right