On Sat, May 1, 2010 at 10:08 AM, erik quanstrom <quans...@quanstro.net> wrote: >> erik quanstrom wrote: >> > i think it's mainly a question of getting the best graphics >> > performance. but these days the 2d accelleration (especially >> > for radeon) is fairly poor. >> >> Do you happen to have any workloads where this is a problem? There is >> a lot more we can do for the radeon, particularly the r100-r300 chips, >> which could improve draw performance. > > i didn't make it clear that i'm using the vesa > interface. and it's very slow for every day > use with acme, but it sure displays pictures quickly. > > ; pci | grep vid | grep 1002 > 1.5.0: vid 03.00.00 1002/791e 10 0:d800000c 134217728 1:00000000 16 > 2:fbff0004 65536 3:00000000 16 4:0000a001 256 5:fbe00000 1048576 > ; pci 1002/791e > 1002/791e > ATI Technologies Inc RS690 [Radeon X1200 Series] > >> To ask the radeon gpu to do anything interesting for you, you must >> carry out a series of register writes - for example, to fill a >> rectangle with a solid color, you write the rectangle's color to >> DP_BRUSH_FGRD_CLR (register 0x147c), the start to DST_X_Y, and the >> width and height to DST_WIDTH_HEIGHT. Everything you can ask the >> radeon to do is ultimately done via register writes. > > i wonder if this pio doesn't explain a lot of the slowness. > i would have thought that they would have used a ring.
There is a command processor on the radeon, which we do not initialize; it can share a ring of commands with the host; it can also accept indirect buffers. If the radeon driver (on supported h/w) was too slow for general work, then we could use it, but if its fine right now, there is no need. If we really needed speed, we could go further - currently plan9 video drivers can only accelerate fill and scroll, but in principle the draw path could use any other functionality the card was willing to do for it; for the earlier radeons, the 2D engine can do a lot... for the later ones, we could use the 3d engine in the same style as X's EXA. -- vs
