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 [n=ssp@c-24-61-88-125.hsd1.nh.comcast.net] 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