1 2 3This file is NOT up to date for the New Design! 4 5 6 7 8============== old (pre-ND) contents below ============== 9 10"I just thought it would be usefull if we had some kind of TODO and BUGS 11files in the distribution as it would make it easier to see what is needed 12to be done and what could be done better, instead of browsing through the 13sourcecode. And we whould be able to se the progress literally by the ever 14decreasing TODO file :-)" 15 16 17## BUGS: 18 19All Tseng cards: 20 21* We definitely NEED to fix that color-expansion problem. See Appendix A 22below for a detailed explanation. 23 24* There are still some problems with the HW-cursor. The error message about 25"wrong color selected" is disabled, and the limitation documented. Better 26would be to have a way to dynamically switch to software-cursor mode if the 27color can not be made. HW cursor doesn't work in DoubleScan modes yet (only 28half of the cursor displayed) 29 30* text font sometimes corrupted when going back to text mode. This may be 31related to the order in which registers are restored: the ARK driver first 32restores extended registers before restoring the standard registers for 33excactly this reason. 34 35* The code needs to be heavily reworked to fix all sorts of data type 36problems. The current code will certainly not run on an Alpha. The first 37step is to replace all hardware related variables by CARD8/CARD16/CARD32 38types. 39 40 41ET6000: 42 43* The trapezoid code is disabled because it doesn't comply with the way the 44non-accelerated ("cfb") code does things. This needs to be fixed. 45 46 47ET-4000(W32): 48 49* Hardware cursor support for the W32 is still lacking color support. We 50need to reserve color cells #0 and #255 to make this work. From discussions 51on the development list, it seems the best solution is to allocate these cells 52read-write, and then use them for the HW cursor. We MUST however document 53that this will break some clients which depend on a fixed color in cell #0, 54and some others that rely on the presence of 256 color cells. It will also 55cause cursor color problems when someone uses a local color map. 56 57 58## TODO: 59 60All cards: 61 62* The accelerator on the Tseng devices is capable of much more. Especially 63the pattern support is not used most of the time: It can render a pattern in 64just about every accelerated operation. This means patterned lines, bitblts, 65screencopies, etc. are possible. However, operations like these are very 66uncommon in normal server use, so the speed benefit would go largely unnoticed. 67 68 69ET4000: 70 71* support needs to be added for several clockchips and RAMDACs: 72 - 8-bit RAMDAC support for >8bpp modes: Sierra DACs and possibly others 73 - AT&T 20C49x RAMDAC support is not correct. 74 75* SuperProbe could use an update. It doesn't detect some of the RAMDACs that 76are detected by the driver. 77 78* Several of the color expansion-related accelerations are still only 8bpp. 79It should be easy to use the same trick on those as on the standard color 80expand code (use intermediate buffer, expand data before blitting). 81 82* many of the operations that the W32 family can't support natively (e.g. 83FillRectSolid for 24bpp) can be performed using CPU-to-screen operations, 84feeding the correct (color) information through the ACL aperture. 85 86 87ET6000: 88 89* someone might want to look at how the bitBLT engine of the ET6000 is 90constructed, and come up with some fancy ways of abusing it. We're still 91only using a small part of it (I'm thinking about the compare map and the 92extensions to the MIX hardware compared to the ET4000). 93 94* Mclk support is still lacking (that would also allow MClk-dependent 95maximum bandwidth). 96 97* Apart from the things mentionned above, I think the ET6000 server is 98pretty complete. Some optimisations could possibly be added. Like for 99example some assembler code for calculating a framebuffer address from X/Y 100coordinates. That would help to speed up small blits. 101 102 103======================================================================= 104APPENDIX A: the color expansion problem 105---------------------------------------- 106 107As suggested in the data book, we're doing font rendering using the 108color-expansion (MIX map) capabilities of the Tseng accelerator. 109 110We're using a ping-pong buffer scheme (triple buffering actually) in 111off-screen memory to store one scanline worth of font data at a time. each 112of these scanlines is "blitted" to on-screen memory using the accelerator. 113The scanline is the MIX map, and there's also a 4x1 solid foreground color 114(SRC map), and a 4x1 solid background color (PAT map). 115 116Basically, the flow is as follows: 117 118 - setup accelerator for font-expansion 119 120 - store scanline 1 in off-screen memory buffer 1 121 122 - start operation 123 124 - store scanline 2 in off-screen memory buffer 2 125 126 - start operation 127 128 - store scanline 3 in off-screen memory buffer 3 129 130 - start operation 131 132 - store scanline 4 in off-screen memory buffer 1 133 134 - start operation 135 136 ... etc, until the whole line of text is drawn. 137 138There is no explicit "waiting" for the accelerator to finish an operation 139before starting a new one, because it has been set up to add "wait-states" 140when the queue is full. We're aiming to use concurrency between the 141accelerator and the storing of scanlines in the buffers. Anyway, waiting 142after each operation doesn't help. 143 144Now, in 99% of all cases, text is rendered OK. But in some cases, we're 145seeing severe font corruption. 146 147What we're seeing is this: sometimes, exactly 32 pixels of a scanline are 148rendered with the scanline data that was there BEFORE, instead of the one 149that was just written into the scanline buffer. In other words, 32 pixels of 150line 2 (for example) are rendered at line 5. The rest of the scanline can be 151OK (i.e. data from scanline 5 is actually written there). 152 153Here's an attempt at showing you what _should_ have been rendered: 154 1551 1562 ##################################################################### 1573 1584 1595 1606 ##################################################################### 1617 1628 1639 16410 ##################################################################### 16511 16612 16713 16814 ##################################################################### 16915 170 171 172 173and what _is_ rendered sometimes (only an example): 174 1751 1762 ##################################################################### 1773 1784 1795 1806 ######################## ############# 1817 1828 1839 18410 ##################################################################### 18511 18612 18713 ######################## 18814 ##################################################################### 18915 190 191At line 6, 32 pixels of the "black" scanline data from line 3 is rendered 192instead of the actual full-white that would normally have to be there. At 193line 13, the opposite happened (data from line 10 rendered at line 13). This 19432-pixel width of the "bug" is independent of the color depth: we're seeing 195this at 8bpp as well as at 16bpp, 24bpp and 32bpp. 32 pixels each time. 196 197Remember, we're talking triple-buffering here, so the "wrongly" rendered 198data is in fact the data that was in the scanline-buffer from the PREVIOUS 199operation that used that buffer. 200 201In fact, my best explanation is that sometimes, a whole DWORD (32 bits) of 202data isn't in the video memory yet by the time the accelerator starts 203rendering with it. 204 205But the data _is_ being written to there by the driver software, because if 206you restart the scanline-operation again, without writing any more data to 207the scanline buffers (only the MIX address and the destination address are 208reprogrammed to restart the scanline color expansion operation -- see code 209in tseng_acl.c), data _is_ rendered correctly. 210 211 212 213I have investigated this as far as I possibly can. I checked if the data was 214actually written in video memory. It was. I checked all kinds of PCI-related 215things, like write-gathering or write-reordering of the PCI chipset, etc. I 216disabled all possible enhanced features, both on the PCI chipset, inside the 217CPU, and on the ET6000. 218 219What strikes me, is that the exact same problems are seen on ET4000W32p as 220on the ET6000. This immediately rules out any special features that were 221only added with the ET6000, like problems with the MDRAM cache buffers, etc. 222It seems to be a generic problem to all Tseng accelerators. 223 224The exact same higher-level code is being used for other chipsets as well 225(i.e. the system of writing scanlines of data to off-screen memory and 226making the accelerator expand it into on-screen memory), and there are no 227problems on these other chipsets. The acceleration architecture we're using 228is completely device-independent up to the point where each chip needs to 229provide a 230 231 SetupForScanlineScreenToScreenColorExpand() 232 233and a 234 235 SubsequentScanlineScreenToScreenColorExpand() 236function. 237 238Since the higher-level code is being used by other chip drivers as well, it 239seems to be OK. 240 241So the problem is either in those device-dependent functions, or in the 242hardware itself. 243 244 245I have found one kludge to work around this problem, and it should (?) tell 246you a lot about the problem: if I start each scanline-colorexpand operation 247TWICE, rendering is suddenly perfect (at least there are so little rendering 248errors that I haven't seen any yet). 249 250 251I am including the two device-depending functions so that you may be able to 252follow what I'm saying here: 253 254 255 256One entire line of text is drawn by calling the Setup() function ONCE. All 257scanlines of text (16 of them in case of a 8x16 font) are drawn by filling 258the off-screen scanline buffers and calling the Subsequent() function. 259 260 261 262 263 264$XFree86: xc/programs/Xserver/hw/xfree86/drivers/tseng/README,v 1.12 2000/08/08 08:58:06 eich Exp $ 265