Re: [Dri-devel] MACH64_BM_GUI_TABLE(_CMD)?
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
Re: [Dri-devel] MACH64_BM_GUI_TABLE(_CMD)?
On Friday 03 May 2002 09:49 am, you wrote: As I was studying the specs and code to be able to understand and reply to Leif's previous post (which I haven't completed yet..), I noticed at the same time a bug and a feature which could mean that blind client buffering could be insecure after all. After testing, it doesn't appear to be. 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). The MACH64_BM_GUI_TABLE_CMD is an alias in this block exactly for this purpose, i.e., to be streamed trhough the GUI command FIFO, as said in its spec (8-12). Doesn't this means that we can initiate further GUI master operations from a command buffer since, once the first GUI master operation is setup, it's only necessary to set MACH64_BM_GUI_TABLE_CMD and MACH64_DST_HEIGHT_WIDTH to fire it up - both accessible from GUI FIFO. Since, upon examination, many of the pieces of documentation we have gotten for the display chips are either incomplete, testing a theory is the best way of knowing whether or not something will do what you expect. I thought that it might be that way, so I tested to see if I could I could re-submit new GUI-master operations to the engine. It appears from the tests that I ran that the GUI-master operation only works with GUI setup and GUI comand registers. Setting up a new GUI-master or BLIT operation did nothing and seemed to just leave the registers set with those values (this was for one descriptor entry's worth of data- we may need to set up a test with MUCH larger spaces with the code in place to be certain...) no actions were carried out (probably because they're not FIFOed and the engine WAS busy...). Although firing up a stream of arbitrary commands shouldn't be a reason for concern since the commands are only innocent(?) GUI operations, this gives the ability of setting up any descriptor table. One consequence is that if this table is invalid the whole DMA engine is unnoperational until a cold reset. Another is that they can access to any register... Yes, and they can set it to any value, but the engine doesn't seem to act on any command settings done this way. It is one of the reasons why I said we ought to push a few register reset operations on some of the critical registers (BUS_CNTL, for example) so that if something DOES initiate a command immedately afterward that expects the settings that were there prior to a DMA pass they won't be broken. You can set up a new descriptor table, but there is no direct way to fire it off after the pass is over with and you can't do it in the middle of a pass (Because your GUI commands needed to fire off a pass are NOT put in the FIFO, they're executed directly from the bus-mastering engine...)- so, if you reset the bus-master control registers at the end of a pass, there will be nothing a malicious client could do to initiate their own passes, bogus or otherwise. I plan to build a test case for this, but I would like to hear preliminary opinions about this, in case I'm missing something. Frank, have you tested this before? Yes, pretty extensively, but I didn't have time to set up tests for spanning multiple pages- we ought to do that one last one before commiting to the path we're now looking at. -- 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
Re: [Dri-devel] New focus for DRI? --- 3DLabs P10 VPU, seems to be hot silicon
On Friday 03 May 2002 01:38 pm, Dieter Nützel wrote: http://www.anandtech.com/video/showdoc.html?i=1614 Regards, Dieter If they'll let some of us (either the TG people or the independents) have info, yeah. If not, it may be problematic for them and they'll have to do something like NVidia did. -- 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
Re: [Dri-devel] New code in mach64-0-0-3-dma-branch: how to approach?
On Fri, 3 May 2002, Felix Kühling wrote: However, when exiting the X server, I get a hard lockup. I haven't found Maybe this is related: whenever the X-server exits I get the following messages at the end of XFree86.1.log: Fatal server error: Caught signal 11. Server aborting So far it hasn't caused any real trouble so I didn't bother reporting it. But if this happens before or during the card is reset for text mode this could cause a lockup. I've narrowed this down a bit. The problem happens in the pScreen-CloseScreen callback in ATICloseScreen (atiscreen.c), which is after the kernel cleanup and ATIDRICloseScreen (atidri.c). I've haven't figured out what function the callback points to yet. Does anyone know where to look for this? -- Leif Delgass http://www.retinalburn.net ___ 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
[Dri-devel] Real moneymaker 2187FdSS0-913UpB-15
Warning Unable to process data: multipart/mixed;boundary==_NextPart_000_00B1_48A26C3B.E2657A85
[Dri-devel] Very dark scenery in fgfs with tcl-0-0-branch
Running FlightGear with the latest XFree86 4.2.0 code (ie, xf-4_2-branch) and the latest code from the DRI tcl-0-0-branch I get very dark textures, particularly close up: http://himi.org/stuff/fgfs-screen-tcl.png (~270kB) Running with RADEON_NO_TCL=1 gives much brighter textures: http://himi.org/stuff/fgfs-screen-no-tcl.png (~200kB) I'm not sure when this started - it looks like some of the screenshots Martin Spott posted from March showed the same thing, but I haven't checked out older CVS code to try and track it down. Simon -- PGP public key Id 0x144A991C, or ftp://bg77.anu.edu.au/pub/himi/himi.asc (crappy) Homepage: http://bg77.anu.edu.au doe #237 (see http://www.lemuria.org/DeCSS) My DeCSS mirror: ftp://bg77.anu.edu.au/pub/mirrors/css/ msg04388/pgp0.pgp Description: PGP signature
