On Friday 03 May 2002 11:08 am, you wrote: > I think the reason for the alias is that the card increments the > GUI_TABLE_ADDR @ BM_GUI_TABLE as it consumes descriptors, so writing to > BM_GUI_TABLE could disrupt a DMA pass in progress. Using the alias > ensures that the commands already in the FIFO/command buffers are > processed before changing the table address. However, as you say below, > it could potentially be used inside a command buffer as well.
I tested that in my tests as well. What appears to happen is as follows: The alias is queued up in the FIFO and is synced against the stream. The other is immediately executed and if you're busy, changing it doesn't seem to do anything other than change it after the fact. Attempts to alter the head of the descriptor table or my position in the table didn't do anything and the descriptor table that was specified seemed to execute correctly. Now, for longer chains, it may be that it is a problem- I only tested for one 4K page of data. > > Only commands which are on block 0 of MMIO region can be streamed into a > > GUI master operation, as said in the BM_DATA register spec (8-11). > > This can't be right since the setup engine registers are in block 1 and we > are using them in a GUI master op. That's what BUS_EXT_REG_EN @ BUS_CNTL > is for. I think that it's more of something like the engine only works with GUI engine commands, of which most of them are in Block 0. I've found that the documentation's a good starting point, but it's not consistent or completely accurate. > We definitely don't want clients changing the descriptor table head from > inside a dma buffer. It currently appears that the chip won't let you do that, thankfully. > If it's really possible to do this, you might be able to set up a blit > as well. This doesn't constitute a GUI operation, and it doesn't seem to let you do anything other than issue stuff to the GUI registers with any effect. I tried every one of the possible stunts to get the engine to do something untoward and couldn't get it to do anything other than rendering commands. A BLIT, while we think of it as a GUI operation, isn't one as far as the chip is concerned, it's a DMA operation- which doesn't get acted upon until the current pass is completed. > btw, I also noticed that HOST_CNTL has a bit for big-endian translation of > host data. At 15 and 16bpp, it swaps bytes within each word and at 32bpp > it reverses the order of the 4 bytes within each dword. This might fix > Peter's texture problem. I do believe that might be what that is there for... > Yeah, the first thing is to determine if it's really possible to kick off > a second DMA pass from within a DMA buffer. Already done, but if you want to reverify (just in case I may have missed something, i.e. since I didn't test past one descriptor entry, it might be that under some cases there's a loophole that allows someone to arbitrarily fire off their own DMA operations...)- go right on ahead. I want this to be the best performing solution for the chip, but also the most secure possible. -- Frank Earl _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
