Re: [Dri-devel] Re: Copying DMA buffers in Mach64
On Tuesday 22 October 2002 03:00 pm, you wrote: But wouldnt it be nice to allow the graphics card to directly access the data from user space ? It seems to defeat the whole point of DMA, if you have to do multiple copies of the data. DMA allows you to do other things while the display chip's busy. DMA with the RagePRO isn't safe (as in, can be reliably secured against malicious clients using it to do exploits, etc...) so you have to audit the stream and unmap the buffer (which will cause all kinds of cache miss pains per Linus...) or copy the data across and DMA it from there. The copy method is probably going to be faster than an audit and unmap because everything is in cache with the copy operation. -- Frank Earl --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Fail To Compile Code When CONFIG_DRM Is Set
On Wednesday 29 May 2002 02:54 pm, Felix Kühling wrote: I had an SIS 6326 one or two years ago and tried to make it work with XFree 4.0.2, I think. I figured out that the SIS DRM needs the SIS framebuffer driver. However, it does not work with SIS 6326 (at least it didn't use to). My conclusion from this is that the SIS DRM does not work with the SiS 6326 either. Can someone confirm this? That would be correct. The DRM is intended for the 300 series of display chips (which figure in the 630/730 motherboard chipsets...). SiS produced the code handed it off to the community without access to the information to improve/repair the code and then dropped support of the same. They're annoyingly uncommunicative about programming information for the 3D portions of the chips (I happen to have 2D and MPEG decode support info under NDA, but not the 3D stuff. While I could probably hack some improvements to that situation, I'm not as inclined because I've got no info on the tuning, etc. of the 3D support.) -- Frank Earl ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] SiS Xabre
On Tuesday 28 May 2002 06:34 pm, Al Tobey wrote: Since it seems to be my turn to spam the list... Has anybody talked to SiS about this beastie (Xabre) yet? It's brand new and I can't even find a card for sale, but there are a few reviews floating about the net. Might be nice to get a decent card supported in DRI before it hits EOL ;) After having attempted to get something going with them through my employer trying to support both the 300 and the 315 (Their then current card that is now out on store shelves...), I'd say that it's an uphill battle. We have an NDA with them, but they won't disclose anything other than the 2D and MPEG support portions of the chip to us. -- Frank Earl ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Fwd: Re: [Dri-devel] Mach64 dma fixes
On Saturday 25 May 2002 12:10 am, Leif Delgass wrote: So it would appear that allowing clients to add register commands to a buffer without verifying them is _not_ secure. This is going to make things harder, especially for vertex buffers. This is going to require copying buffers and adding commands or unmapping and verifying client-submitted buffers in the DRM. I'd like to continue on the path we're on until we can get DMA running smoothly and then we'll have to come back and fix this problem. Check back to what I'd said for my work- how I'd envisioned things working. It doesn't really rely on a register being set. Yes, it uses a register to verify a completion of a pass, but the main way to do that is to see if the chip's idle- it's more of an extra, redundant check. If the chip is idle, we know it's done with the pass. If it's not idle after about 3-5 interrupts, you know it's probably locked and needs a reset. Now, with the DRI locks, etc. we can ensure that we know there's going to be nobody that isn't a client pushing stuff out until we're done and flagged as such. We also know that nobody's going to be allowed register access, so they can't keep the engine on the chip busy except by DMA requests. DMA requests are not initiated by the the callers, they're handled by a block of code tied to an interrupt handler in the module. This code, if it gets the lock, submits a combined DMA pass of as much of the submitter's data as is reasonable. We then check to see if that pass is completed every time the interrupt gets called. Upon completion, you unlink the buffers in the pass and hand them to the free list. With that, you're already as secure as you're likely going to get with the Mach64- the DRM is in the driver's seat the whole time for any submitted data. Otherwise, you're going to be doing copying of some sort, which pretty much burns up any speed advantages the optimal way of doing this gives you. -- Frank Earl ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 dma fixes
On Saturday 25 May 2002 03:01 am, José Fonseca wrote: Wow! Bummer... I already had convinced myself that the card was secure! It is, if you don't rely on a register being set by something for your control of things. You may get peak performance with the design in question, but it's not secure. I'd almost bet we could get as good a performance doing it with what I'd started, if we re-worked the interrupts so that we got double them up using the scanline one in addition to the VBLANK one. Yep. It's not the end of the world, but it's gonna mean that the CPU will be a little more stressed, and that we have much more code to do... If you guys don't mind, I'd like to revisit the work by modernizing my branch and finalizing what I'd started. I think it'd do well and make it secure -- Frank Earl ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 dma fixes
On Saturday 25 May 2002 11:48 am, José Fonseca wrote: On 2002.05.25 17:16 Frank C. Earl wrote: Frank, Leif was pretty clear and I quote: it IS possible to derail a bus master in progress and set it processing from a different table in mid-stream. Plus, if the address is bogus or the table is misconstructed, this will cause an engine lockup and take out DMA until the machine is cold restarted. And this can happen regardless if a specific register is to be read or not. (In fact, if you look at the test case you'll see that no register is being read except for debugging purposes.) Yep. I looked at his example again and it just didn't initially click when I looked at it the first time- I really do need to NOT post things just after waking up... This is extremely disappointing to say the least. Doing the copying is going to eat at least part if not all the advantage of doing either route. -- Frank Earl ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 dma fixes
On Saturday 25 May 2002 11:56 am, you wrote: What prevents a client from modifying the contents of a buffer after it's been submitted? Sure, you can't send new buffers without the lock, but the client can still write to a buffer that's already been submitted and dispatched without holding the lock. Nothing. If the chip had been as secure as we'd initially thought, it would have not mattered because all they'd do is scribble all over the screen at the worst. If you're unmapping on submission, you don't have to lock things on the client end because they can't alter after the fact. Then you only have to worry about bad data. In this case, what you're going to want to do is to unmap, build the real structure by filling in the commands for the vertex entries, and submit to the processing queue. Multiple callers could then still submit what they wanted to be DMAed without waiting (in the current model, don't each of the clients have to wait if one's got the lock?) because there's a peice of code multiplexing the DMA resource instead of a lock managing it. I don't see the interrupt method being that different from a security perspective. The DRM is in the driver's seat in either case, the method without interrupts is essentially the same, but with the trigger for starting a new pass in a different place. The problem isn't just relying on reading registers that can be modified by the client, but ensuring that the client doesn't add commands to derail the DMA pass or lock the engine. The only way to make sure this doesn't happen is by copying or unmapping and verifying the buffers. I think the i830 driver does this. Yes, it will impact performance, but I don't see a way to get around it and still make the driver secure. At least this extra work can be done while the card is busy with a DMA operation. If it had been secure and you couldn't derail DMA, it wouldn't have peices that could be confused by malicious clients, meaning you didn't need to do copying, etc. to secure the pathway, ensuring peak overall performance. With your latest test case, it's a moot point. We're going to have to secure the stream proper in the form of code that has inner loops, etc. (The i830 does an unmap and a single append only- we've got a lot more to do with the Mach64. I've been thinking of ways around that on the i830 and i810 that I'm going to be trying at some point.) Your way would be as secure in this environment. Now, as to which is more effiicient, that's still up to debate. I can't say which is going to be faster overall. There's the aging in your design that allows for buffers being released sooner than in mine. There's the need for serialization in your design that is unrequired in mine. Which causes the worst bottlenecks in performance? -- Frank Earl ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 dma fixes
On Saturday 25 May 2002 11:48 am, José Fonseca wrote: So if you can't secure it in the end, your extra effort will be in vain. I just thought of something to try to change the nature of the test case problem. What happens if you have a second descriptor of commands that merely resets the DMA engine settings to what they should be for the third descriptor? I'd say it'd depend on what the chip was actually doing- what do you guys think? -- Frank Earl ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 dma fixes
On Saturday 25 May 2002 01:14 pm, Leif Delgass wrote: I'm using the same model you had set up. When a client submits a buffer, it's added to the queue (but not dispatched) and there's no blocking. The DRM batch submits buffers when the high water mark is reached or the flush ioctl is called (needed before reading/writing to the framebuffer, e.g.). Clients have to wait for the lock to submit the buffer, but the ioctl quickly returns. The only place where a client has to wait is in freelist_get if the freelist is empty. That's where buffer aging or reading the ring head allows the call to return as soon as a single buffer is available, rather than waiting for the whole DMA pass to complete. I guess I misunderstood somewhere. Then the only real question is, can we safely/stably manage aging or do we need to do it the way I had planned? Got it. For vertex data, we can add the register commands based on the primitive type and buffer size. By placing the commands, we can ensure that any commands in the buffer would just be seen as data. This would require an unmap and loop through the buffer, but we wouldn't have to copy all the data. I'm going to try doing gui-master blits using BM_HOSTDATA rather than BM_ADDR and HOST_DATA[0-15] and see if we can elimintate the register commands in the buffer. We could also use system bus masters for blits, but that would require ending the current DMA op and setting up a new one for each blit, since blits done this way use BM_SYSTEM_TABLE instead of BM_GUI_TABLE. With BM_HOSTDATA it would be a matter of changing the descriptors for blits, but they could co-exist in the same stream as vertex and state gui-master ops. It's still something eating cycles that if we could have secured the chip better that we wouldn't have to be doing. Unmapping's not a good thing to be doing with something you're trying to do quickly and it's rough on the kernel memory system. Now, as to which is more effiicient, that's still up to debate. I can't As I explained above, serialization isn't needed. It's really a question of which method of checking completion and dispatching buffers leaves the least amount of idle time. Buffer aging could still be used in the interrupt driven model, so that's not really a constraint of one approach versus the other. I don't think it would be too difficult to test both methods without too much change in the basic code infrastructure. Works for me. -- Frank Earl ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 dma fixes
On Saturday 25 May 2002 03:44 pm, Leif Delgass wrote: This had crossed my mind too. The only problem is that there could still be a short period of time where BM_GUI_TABLE isn't accurate, so it still leaves the problem of being able to trust the contents of BM_GUI_TABLE for buffer aging and adding descriptors to the ring. Yeah, but that's only a problem if you're aging them. This is more food for thought type stuff at this point- it all boils down to what is the most optimal secure way of doing things. The less things we do per submission, the better. We may still end up un-mapping things, but pushing out 8 bytes for each 4k is less work than pushing out a command every vertex in the buffer. I'd love to come up with a way to not have to un-map things if at all possible so that we're not doing that either. Like I said, it's not really something you want to do often (just like you don't want to do ioctls all that often either... :-) -- Frank Earl ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 dma fixes
On Saturday 25 May 2002 03:50 pm, Leif Delgass wrote: It just occurred to me that resetting BM_GUI_TABLE could put the card into a loop. You might have to put in an address two descriptors away. We'd need to test this. Hmm... Didn't think about that possibility. I had this last line of thought while I was mowing the yard (still doing yardwork...). I was going to plug in your test case, the one José just came up with, and my proposed one into my test driver code and see what comes out from all of it. -- Frank Earl ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 dma fixes
On Saturday 25 May 2002 04:27 pm, you wrote: Anyway, this doesn't prevent to use the buffer aging. On the end of processing a buffer we still end up with the correct value of BM_GUI_TABLE and we can use the last bit of BM_COMMAND to know if it's processing the last entry or not. The only draw back is that we aren't able to reclaim the buffers so soon, so we would need a scratch register to know which buffers were free or not. But then, what damage can a client do by tampering BM_COMMAND? Even if it can mess with BM_COMMAND, we can still work without it. We just let the card go on, but when it stops we just need to see wich was the last processed buffer and go on. But probaby there are more registers that the client can mess and damage... probably is not just BM_GUI_TABLE and BM_COMMAND, but a bunch more of them, and we're effectively reducing the card communication bandwith asking to reset so much thing in the end of _each_ 4kb buffers. We're just going to have to play with it. As far as I'm concerned, we're going forward with things as they are at this point. I'm just spending a little of what little time I do happen to have exhausting all possible ways of avoiding doing unneeded operations- as long as my branch is mostly in lock-step with the functionality that you're providing I'll be happy. I'll not spend too much more time trying this stuff, but I want to know. If something comes of all of it, great. If not, well, it was my time to waste and it's not really wasted- we'll have answers when someone else comes along and asks if that's the best we can do with this chip. I'm just not liking having to secure the path the way that it's being thought of. Not because I'm against doing the work- there is a bottleneck in doing this stuff that way. Some of the things we would do to secure things don't consume a lot of resources CPU-wise. Some of the things we would do if we can't just ignore the path would consume a lot of resources. If the books covering the design of the Linux kernel are to be believed, there's a decent number of operations done by mapping or unmapping memory to/from userspace- it really wasn't designed with the kinds of stuff we're asking of it (namely doing a LOT of it and doing it quickly and often...) in mind. Yes. Unfortunately I don't have the time to do it myself, so it will have to wait in what concerns me. I'm planning on setting things up this evening to see if any of this is worth bothering with as a continuing conversation. In any event, I think what these issues must be really addressed only when the DMA is complete. Our knowledge of the card behavior is constantly changing, and it would be waste of time to make such an effort to make things work out and discover later on that it was hopeless. Indeed. That's why I intend on tinkering a little while longer with this but only so much so. As for knowlege of the card behavior changing and whatnot. I'd believe that not everything is known about any of the other cards out there. In fact, although I try to stay impartial and have an open mind about this, I can't stop thiking that we aren't going to accomplish nothing with circunveining the card's security drawbacks like this. It's like covering the sun with that-thing-full-of-holes-which-I-dont-recall-the-name... I'm getting more and more inclined towards a robust implementation, like unmapping buffers, which probably won't have a significant performance impact, and which will give us much freedom to control the card properly. Well, time will answer this... That's my take on things... -- Frank Earl ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: installing tv out for rage LT pro (fwd)
On Saturday 25 May 2002 06:07 pm, Leif Delgass wrote: Does anyone have any ideas on this? I haven't seen compiler messages like this before when compiling the drm. Did Gerard indicate what distribution and C compiler he was working with? This is the same bizarre things I usually saw when attempting to compile the kernel sources included with earlier versions of Mandrake. -- Frank Earl ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 dma fixes
On Thursday 23 May 2002 04:37 pm, Leif Delgass wrote: I've committed code to read BM_GUI_TABLE to reclaim processed buffers and disabled frame and buffer aging with the pattern registers. I've disabled saving/restoring the pattern registers in the DDX and moved the wait for idle to the XAA Sync. This fixes the slowdown on mouse moves. I also fixed a bug in getting the ring head. One bug that remains is that when starting tuxracer or quake (and possibly other apps) from a fresh restart of X, there is a problem where old bits of the back- or frame-buffer show through. With tuxracer (windowed), if I move the window, the problem goes away. It seems that some initial state is not being set correctly or clears aren't working. If I run glxgears (or even tunnel, which uses textures) first, after starting X and before starting another app, the problem isn't there. If someone has a cvs build or binary from before Monday the 20th but after Saturday the 18th, could you test to see if this happens? I'm not sure if this is new behavior or not. I tried removing the flush on swaps in my tree and things seem to still work fine (the bug mentioned above is still there, however). We may need to think of an alternate way to do frame aging and throttling, without using a pattern register. I've been pondering the code you've done (not the latest commited, but what was described to me a couple of weeks back...) how do you account for securing the BM_GUI_TABLE check and the pattern register aging in light of the engine being able to write to most all registers? It occured to me that there's a potential security risk (allowing malicious clients to possibly confuse/hang the engine) with the design described to me back a little while ago. -- Frank Earl ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 bus mastering abilities (partial test results)
On Tuesday 14 May 2002 10:01 pm, Ian Romanick wrote: This is just a crazy suggestion, but has anybody talked to any ATI engineers to find out how they do it in win32? Your idea sounds very good, but I'd still be curious to hear how (or if!) ATI solved this problem on Windows... I've been told we're pretty much on our own. I had to press my luck with this to get the info on a host data error interrupt/reset, which was mentioned in the documentation but not offered. I guess we could pester again, but I really don't want to burn bridges- I want to see the Radeon 8500 supported as open source, etc. If this works out, great. It's still going to have stalls. If it doesn't work or isn't safe, we've still got some stuff in hand to lower the amount of stall time that we've discussed on IRC (Which is to set the chip to interrupt on the VBLANK and when it hits the midpoint scanline- that's something like 120-160hz which is probably much more than the chip could handle in rendering performance. I'm still voting for that one because it gives cleaner error recovery...) -- 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] Re: Mach64 bus mastering abilities (partial test results)
On Wednesday 15 May 2002 06:51 am, Leif Delgass wrote: I'm getting close to committing this now. I got gui-master blits working, and pseudo-DMA is stable. Actually, the pseudo-DMA is probably faster without blits, but I'm hoping that it will help with DMA. The DMA is still prone to lock-ups, but most of the time it's recoverable. What's it doing when it isn't recoverable? (Oh, and can you flip me a diff of your sources from the current CVS? I've got a little time and I want to tinker a little bit...) -- 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] Client context uploads: How to implement them? / Analysis of the Gamma driver
On Sunday 12 May 2002 01:15 pm, Leif Delgass wrote: this working, I've used buffer aging rather than interrupts. What I realized with interrupts is that there doesn't appear to be an interrupt that can poll fast enough to keep up, since a VBLANK is tied to the vertical refresh -- which is relatively infrequent. Depends on what you're trying to do with it. If you're polling for completion of a pass for a given caller, it may be problematic. Should we be doing that with this chip, though? I had envisioned a scheme in which the clients didn't drive DMA, they simply submitted things to be rendered out by the chip's DMA and the DRM managed details of keeping track of completion, etc. The first pass of the code I was working towards was going to rely on a lack of free buffers to throttle the clients accordingly. If that didn't work as I had hoped, I was looking to use async notifications to tell clients the request had been processed. In that model, the only things needing to deal with locks are the DRM engine code submitting the DMAable buffers or blits (ran by a seperate group of code...) and any clients/code directly manipulating the chip. All DMA engine clients do is ask for buffers, fill them, and then queue them up for submission to the chip's gui-master engine. The interrupt handler takes care of the rest. In that picture, you're not submitting one group of buffers for one client to the chip, you're submitting as many buffers as you think you can get away with at 60+ Hz (something like 1-2Mb, from prior experience with the Utah-GLX code...) from the queue submitted by all clients. The DRM lock scheme would give enough flexibility to allow the X server to squeeze in against the DRM DMA handler and vice-versa so that screen updates and other stuff could be managed. Unfortunately, my lack of available time precluded me from coding in more than the base framework for that scheme. -- 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 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 Wednesday 01 May 2002 03:58 am, JosX Fonseca wrote: Frank just commited a set of changes to the mach64-0-0-3-dma-branch. Is in own words: Most of the first cut of the DMA code. It's got most of the dispatch architecture in place (Lacks actual DMA submission (The easy part, really...)) so it's not done yet, but I promised people that done or not, I'd do a check-in of this... Yeah, if you'll remember, I said that I'd complete the code/test it barring fate handing me another full plate. Well, I probably shouldn't have made that comment, because I didn't get much of any coding done last week. I won't bore you w/the details, suffice it to say that I had to scramble to try to fix my financial situation due to my so-called employer's not paying me consistently. The part which is missing is more or less what we have in the mach64-0-0-4-branch, except that the state update is still being made with MMIO. So either we add the remaining parts to mach64-0-0-3-branch or we bring Frank's changes to mach64-0-0-4-branch. Personally I'm more in favor of the later, since it will avoid redundant work of merging back and forward, and will also enable the PowerPC architecture to participate in testing. I'm for it, I was going to actually consider doing that very thing but the fun on my end of things just kept me distracted enough that I couldn't sit down and just code the whole thing. For the record, NEVER stay around at a company if they don't do a consistent and regular payroll run at the appointed times per their policies- any inconsistencies show in that situation, you should leave it right then and there. So before we starting the merge, it's needed to include the state update in the buffers. Although I still have some concerns about security, the fact is that the only security problem we've seen so far is that a malicious client can lock the card (by setting a 0 texture address offset) and is not clear that we can recover from that too. I was able to make it recover from the locked state with DMA, etc. with the XAA FIFO size change by using the reset code in the mach64-0-0-3-dma-branch. Something to check would be to see if a 0 texture address offset would hang things with the interrupt (another reason for having it...) handler checking to see if we're locked up solid. I couldn't get the X server to do it's usual lockup behavior (if you ran X after doing the DMA test with the little testbed driver, it'd lock up tight...) when I inserted a forced reset like the one in my submitted code- and the DMA code worked just fine after startup (Of course, it reset the FIFO size...). -- 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] How to allocate DMA memory
On Wednesday 24 April 2002 06:15 am, you wrote: Hi, there! For enabling DMA on Mach64 I'll need to allocate two extra DMA buffers: a primary DMA buffer and a decription table buffer. All you need for now is a descriptor table. The buffers that you have already allocated via the DRM's framework should be allocated page aligned and you'll have the bus address in hand. The only reason you'd need a primary buffer is if you had an engine that wasn't at all secure (The RagePRO's pretty much secure, it won't let you set up DMA sessions, etc. and you can undo anything that might cause confusion in the engine at the end of the pass (Use the Utah-GLX code for the closeout of a DMA pass for a hint there...).) and you're securing the vertex path. For now, I'd be seeing what you can do to just get it going. All you need is a descriptor table at that point. Use the memory pool api to allocate that one just like in the BUS-Master test. At that point, we'll have a DMA system (Though it ties up the framework for any given pass- the code I'm completing happens to have a full-blown queue, etc that is governed by the CTRC interrupt.). It may not be quite what I have in hand, but as Gareth has said before, get it working- I'm just waay to busy to have completed what I had in mind up until recently. -- Frank Earl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Pseudo DMA?
On Thursday 07 February 2002 12:37 pm, Jose Fonseca wrote: Could someone of the 3D gurus enlighten this question? More specifically, what is pseudo DMA and what is the relationship between DMA and the PIO and MMIO modes? psuedo DMA is where you pass a DMA-able command buffer to an interpreter engine that then submits the commands via MMIO. It's of mixed use- it's slower than straight MMIO, if you've got the command structure figured out it can give you a litmus to tell you if you've got problems with the DMA pass (Ex. It ran in psuedo DMA, why isn't it working right in DMA? The mach64 has an issue with PPC machines where it just isn't happy with one of the gears rotating in gears, but only if it's being DMAed to the chip- PDMA works fine and both work as expected on x86 platforms... I still haven't quite figured that one out yet.) -- Frank Earl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 DMA
On Sunday 10 March 2002 11:44 am, José Fonseca wrote: I really don't know much about that, since it must happened before I subscribed to this mailing list, but perhaps you'll want to take a look to the Utah-GLX and this list archives. You can get these archives in mbox format and also filtered with just the messages regarding mach64 at http://mefriss1.swan.ac.uk/~jfonseca/dri/mailing-lists/ The problem was that the XAA driver for mach64 was setting the FIFO size up for some reason and it was leaving the chip in a state that wouldn't work for the DMA mode. If we set the size back to the default setting before we do the first DMA pass, everybody's happy. I suspect if we got with the developer of the XAA driver we can sell him on leaving that setting alone in the driver's setup. Sorry for being silent for so long gang. Been, yet again, crushed under with lovely personal business. I have started a new branch (mach64-0-0-3-dma-branch), and I'm actually putting the hacks I've been playing with into a unified DMA framework. I should be putting the first updates to the branch in over the next couple of days. Of note, when I did find some spare time, I ran tests on what we needed to do to secure the chip's DMA path. I found out some interesting facts. It will accept any values written to the registers. It will not act on any of those settings during the DMA pass unless they're a GUI specific operation when it's doing a command-type DMA. It will not act on many of the settings after a DMA pass is complete. It will not let you set up any sort of DMA pass during the operation. Junk commands, by themselves, do not seem to hose up the engine in operation. Mapping and unmapping a memory space is somewhat compute intensive. -- Frank Earl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 DMA
On Sunday 10 March 2002 04:36 pm, José Fonseca wrote: I didn't fully understand the implications of above, but shouldn't the direct access to the chip registers still be denied to clients? Depends. Looking at the gamma source code (I could be wrong, mind...) it appears that the DRM is taking in direct commands from userspace in DMA buffers and sending them on to the chip as time goes along. If you can make it so that it doesn't lock up the card or the machine and doesn't compromise system security in any way (i.e. issuing a DMA pass from a part of memory to the framebuffer and then from the framebuffer to another part of memory so as to clobber things or to pilfer info from other areas), it's pretty safe to do direct commands. From observations, it appears that you can't get the engine to do anything except GUI operations during a properly set up GUI-mastering pass. The only risks that I can see right at the moment with sending direct commands over indirect commands is one of not resetting certain select registers to what they were before the pass and one of the engine not handling certian GUI operations well. The first is easily taken care of by having the driver have a 4k block submitted in the descriptor chain as the last entry that updates those registers accordingly- the list of commands should only need to be built once and reused often since these registers won't be changed by the DRM engine, Mesa driver, or the XAA driver after the XAA driver does it's setup for the chip operation. The second case is a tough one and one that copying/mapping won't protect you from it- you have to process commands to prevent them from occuring (compute intensive and there might be other cases, each time you'd have to come up with yet another workaround) or find something to detect a hang on the engine and reset it proper. I seriously doubt that we'd encounter one of those, but we might all the same. I've still got one or two more tests to run (I've yet to deliberately hang the engine, detect the same, and then do a reset- but then I've yet to be able to hang the engine with it _properly_ set up...) but most of the innards for copying commands or whatever would be largely the same (some of the interfaces might change, but that's less of an issue than the heart of the DMA engine itself which is the same no matter what...) so I'm going to get _SOMETHING_ in place to see what our performance actually would be with some DMA operation going on. Mapping and unmapping a memory space is somewhat compute intensive. This one has to be compared to the time that takes to copy a buffer, unless there is a way to do it in a secure manner without copying or unmapping. If you don't have issues with sending commands directly, you don't need to copy or map/unmap. You don't need special clear commands or swap commands, you only need to issue DMAable buffers of commands to the DRM engine for eventual submission to the chip. Right now, I'm not 100% sure that the mach64 is one of those sorts of chips, but it's shaping up to be a good prospect for that. -- Frank Earl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Pseudo DMA?
On Monday 18 February 2002 10:35 pm, Keith Whitwell wrote: The rings are in agp space. It's a bug in the security model of the i810, it's arcane, but believe me it's real. Which leaves it open to attack because the AGP space isn't covered by the protection system. Got to wonder what they were thinking with that- to come up with a nice scheme for protecting the system against rogue code submitted from userspace to leave it open like that. I guess they thought it'd be difficult to implement an exploit with that. I ought to read up more on the rings- I got the impression from the documentation that they were just out in memory and were purely DMAed from anywhere in system memory. Thank you for being patient and putting up w/me here... :-) -- Frank Earl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Pseudo DMA?
On Monday 18 February 2002 12:07 pm, Keith Whitwell wrote: The i810 has a security model that makes insecure commands in batch buffers into noops. Unfortunately there is a hole in the security model: you can emit a batch buffer with blit commands in it that blit insecure commands onto the ring, where they may then be executed... I didn't see that in the documentation. If it's only working from the premise that the command stream is untrusted, it's supposed to stop operation at that point. Since the ring buffers are supposed to be in system memory, I'd have thought that if you controlled the buffers so that the rings are NEVER accessable to the user from the driver they couldn't be used to ammend commands to it (real memory access...) with a batch buffer. I'll re-read things since you're claiming different from what I got from it. In addition to unmapping the buffer, the i810 kernel module emits commands into the buffer itself, ensuring that the data can only be interpreted as vertices. Eg, imagine receiving a buffer full of bogus commands from a spoofing app - the kernel module unmaps it from userspace, then writes at the top of the buffer a command that says: emit the next 4096 (or whatever) bytes as a tristrip. No commands from the app can ever be executed. If the commands don't allow any access to anything system memory-wise (which is what you're doing in the command to start the buffer) then they can't overwrite anything or be used to snag memory that doesn't belong to the app. I'd have to double check the source code- I didn't see anything that parsed vertex info into DMA commands in the driver layer. I'd expect that if it's entirely as you claim it is. -- Frank Earl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Pseudo DMA?
On Monday 18 February 2002 01:07 pm, Keith Whitwell wrote: A followup here... I'm looking at the i810 documentation and the source tree now. The i810 has a security model that makes insecure commands in batch buffers into noops. Unfortunately there is a hole in the security model: you can emit a batch buffer with blit commands in it that blit insecure commands onto the ring, where they may then be executed... The documentation lends the idea that it doesn't convert them to no-ops, but rather does the rough equivalent of a segfault, signalling an interrupt on the bus. The hole you describe is an interesting issue though- hadn't thought of that one. Has there been an actual test to see if it was doable from an unsecured batch buffer? I couldn't find any discussion in the list archives as to whether this is a theoretical exploit or an actual one for this chip. In addition to unmapping the buffer, the i810 kernel module emits commands into the buffer itself, ensuring that the data can only be interpreted as vertices. Eg, imagine receiving a buffer full of bogus commands from a spoofing app - the kernel module unmaps it from userspace, then writes at the top of the buffer a command that says: emit the next 4096 (or whatever) bytes as a tristrip. No commands from the app can ever be executed. Ok, I see what the code's doing there- missed it in both my passes over it (Don't know how I missed it- if it'd been a snake...). So the mesa side of things isn't supposed to write in the very first part of the buffer to allow for the insertion of that command, then. Is it a good thing to un-map it _after_ you write in the command at the head of the batch buffer? I'd think it'd leave a loophole in there (because they could sneak in another command in the place of the one the driver is placing)- difficult to exploit, but there all the same. Ugh... Ok, I see, I understand. What a shame. Really, it is- the driver as it stands ends up being SLOWER than a mach64 under Utah-GLX. Yes, Utah-GLX was less secure, but to be so much slower as to have the same gears framerate with a PIII-600 as I got with a PII-450 on a supposedly slower chipset- well, it really sickens me. What's the mach64 card going to end up being like performance wise? Are there any cards out there that don't have seriously borked DMA models that we have to do intrinsically inefficient things just to secure the driver? I had hoped that the i810 would be a workable chipset for the pilot project with my employer's planned product offerings- it would be a slow chip, but it would allow me a way of demoing some 3D games, etc. on a set-top box system. Now, well... -- Frank Earl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Pseudo DMA?
On Friday 08 February 2002 07:09 pm, José Fonseca wrote: Does this mean that client code can lock the card but is not really capable of putting the security of the system in danger? Depends on what you define as in danger. It won't allow a user to commit local or remote exploits to gain root, etc., but it could be used to lock up the console such that it requires a remote session of some sort to do a reboot. This is why, when it passes muster, I'm putting it in a seperate branch- it's usable, and should be fairly stable, but it's not protected from malicious clients, etc. To be a proper secure driver, it HAS to be such that you can't DoS the box via the driver if at all possible. Since there is no specialized groupings of commands (such as one to push a lot of verticies to the card), I would have to create a shorthand system that the module would interpret and then generate the right commands for the DMA channel to use, or come up with a way to detect a lockup on the chip and do a proper reset. The first option has an extra inner loop to process against (It took cycles to FILL the list, now you're taking cycles to unpack and re-express them in a form that the card can handle...), eating cycles that could be used elsewhere in the system. The second option presumes one can detect cleanly a locked up chip always and do a reset always. Sorry for the dumb question (my knowledge of the DMA mechanism is still rather incomplete..), but in what way the distinction of the set of commands (in the DMA buffers I presume) affects the security? Depends on the chip. In the case of the RagePRO, there is literally nothing keeping you from submitting commands in the DMA stream that can lock up the chip. Not very many (if any of them...) of the routines in the XAA driver for the RagePRO expect a hung card (because they're not doing anything that COULD lock the card) and there's a couple of locked up states from the DMA pass that leave the engine state as being busy forever- and end up being deadlocked, thus hanging the console but good. If the XAA driver and the kernel module could check unobtrusively for a locked up state and do a reset if it is locked up, the situation would go from being an insecure one to a relatively secure one (As secure as it's going to get and not impair performance...) -- Frank Earl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Pseudo DMA?
On Friday 08 February 2002 11:03 am, Jose Fonseca wrote: Keith, is pseudo DMA a hardware feature of Matrox cards or just a software hack for debugging purposes? I'm not Keith, but I'll venture an answer. It's a software hack that was in the Utah-GLX drivers for the G200/G400 and RagePRO (a.k.a. Mach64). I don't know if it was included in any of the other drivers or not. -- Frank Earl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] SGI transfers 3D graphics patents to MS
On Monday 21 January 2002 09:21 am, Mike Westall wrote: Conversely, if MS considers OpenGL to be dead and buried, period, it seems that Bill would be bit silly to want to spend $62.5 to become the owner of said dead + buried technology!! OpenGL is not really technology- it's an API that drives the technology. MS is very likely shopping more tech for DirectX. -- Frank Earl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 DMA
On Tuesday 08 January 2002 04:12 pm, Leif Delgass and Manuel Teira wrote:
Happy New Year!
Hopefully for all, it will be a better one than the last...
Well, after the holidays, I would like to recover the development in the
mach64 branch. I started today to investigate the DMA stuff because I
think that perhaps Frank is very busy and he has no time to do this work.
The DMA problem was discovered aprox. Oct 21th and we have no news about
any progress in DMA. I'm sure that Frank would do it better than me,
but I can try.
I've had starts and stops. However, I am still working on things and have
been with what time I've actually had that I could think straight on and I'm
pretty close to having something- sorry about the delays on my part, I KNOW
you're all chomping at the bit, I am wanting this to happen as much as you
all are.
It sounded like Frank had written some code already (he mentioned being
halfway done in early December). Frank, is your work in a state that
could be commited to the branch so others could help finish it? If so,
this might be a good place to start a new branch tag since we currently
have a working driver. Before long we'll also need to merge in changes
from the trunk, since 4.2.0 seems close to release.
I'm about ready to actually make that branch- I nearly have the code in place
(You'd not believe the fun stuff that has conspired against me to finish the
code... Job hunting, honey do projects, my father being ill- I couldn't
get focused long enough to sit down and plug the code in... But enough of
that, it's in the past.) and I'm planning on getting it completed sometime
this upcoming week and start verifying that I've not broken anything. I'll
go ahead and make a branch at that point in time.
I've been looking at the r128 freelist implementation, so I've derived
that the register called R128_LAST_DISPATCH_REG (actually
R128_GUI_SCRATCH_REG1) is used to store the age of the last discarded
buffer. So, the
r128_freelist_get is able to wait for a discarded buffer if there's no
free buffer available.
Could this be made in the mach64 driver, say with MACH64_SCRATCH_REG1 ?
In my register reference it says that these registers can be for
exchanging information between the BIOS and card drivers, so, is sane to
use them for this task?
I'm not sure that that would be safe to use. According to r128_reg.h, the
r128 has BIOS scratch registers and GUI scratch registers, where the
mach64 has only the scratch registers used by the BIOS. The mach64
Programmer's Guide says that SCRATCH_REG1 is used to store the ROM
segment location and installed mode information and should only be used
by the BIOS or a driver to get the ROM segment location for calling ROM
service routines.
Hm... I've been wondering why they used a scratch register when the private
area's available and could hold the data as well as anything else. Anybody
care to comment? As it stands, I've got the info being placed in the private
data area as a variable.
I've also seen that there's no r128_freelist_put (it's present in mga
driver, for example). Isn't it necessary?
Depends. I'm not sure how I'm going to code things. I've got to account for
clients holding onto or discarding their buffers upon submission (As well as
burning them off because they're shutting down) in the DRM and I'm working on
this part (The actual DMA submission part's fairly easy, but the trappings
within the DRM are a different story.) right now. My thinking is that if
it's a discard, we push it back into the freelist and view it as unavailable
unless the age is past the timeout point.
And, when is a buffer supposed to be discarded. Is this situation
produced in the client side?
It appears to be a client side behavior. The way that most of the cards seem
to do their DMA is they queue up the buffer in question with an ioctl such as
DRM_IOCTL_R128_VERTEX, using a struct not unlike this for parameters for the
ioctl:
typedef struct drm_r128_vertex {
int prim;
int idx;/* Index of vertex buffer */
int count; /* Number of vertices in buffer */
int discard;/* Client finished with buffer? */
} drm_r128_vertex_t;
idx is the value pulled from the value in drm_buf_t. I'll admit that prim's
still a little foggy to me, but count is obvious as is discard. Basically
the client tells the DRM to put it back into the freelist because it's done
with it. I would think that there is a tradeoff for holding onto versus
releasing buffers- holding onto them would be a speed boost, but at the
expense of limiting how many clients had buffers. 128k's not a lot of buffer
space- it doesn't allow for many verticies, etc. so I'd wonder what kind of
benefit a client would derive from holding onto the buffer for things like
verticies. Textures might be an advantage, but again, you're stealing things
Re: [Dri-devel] Mach64 DMA
On Sunday 13 January 2002 11:50 pm, Gareth Hughes wrote: While we're discussing things here, can anyone tell me why things like the emit state code is in the DRM instead of in the Mesa drivers? It looks like it could just as easily be in the Mesa driver at least in the case of the RagePRO code- is there a good reason why it's in the DRM? Security. Okay. I can buy that as a reason. Unfortunately, the reason why it's more secure doesn't appear to be well documented anywhere and there are several cards that do not appear to have this as a feature of their DRM module- would you (or anyone else for that matter) enlighten us as to the why it's better/more secure? (I'm coding it right now, it just strikes me as adding a bunch of extra kernel space call overhead without much benefit- I'd love to understand why I'm doing it this way while I'm coding it into the DRM... :-) -- Frank Earl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64
On Tuesday 20 November 2001 11:27 pm, you wrote: Yep, that's correct. Had to deal with missing and/or conflicting info to boot... This sounds strangely familiar... :-) -- Frank Earl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64
On Tuesday 20 November 2001 04:36 pm, you wrote: Having said all that, the docs that I have (and most others I think) don't really cover 3D operations (except for register listings). I'm not sure if the DRI project has 3D documentation available for project members. I don't think there's any more available from ATI than what we already have. If memory serves, Gareth and John worked from the register docs and the 2D coding info from the Programmer's guide. -- Frank Earl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Fwd: Re: [Dri-devel] Is there DRI support for a ATI Rage Mobility
On Friday 16 November 2001 12:51 pm, Nick Hudson wrote: I have a ATI Rage Mobility Mach32 card I beleave ... Its in a Dell inspiron 7500 and I was just wondering is there DRI support for it? I was looking for something that might speed up my frame rate. Drivers for the RagePRO family (which includes the original Rage Mobility) are in progress. I am working on the DMA path right now (and as a status update to the group, I've got an aging scheme, etc. to allow the RagePRO DMA to work within the DRI model for things.) and we should be seeing some more stuff as the holidays come around. -- Frank Earl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Xpert98 Rage support
On Monday 29 October 2001 01:04 pm, Robin Forster wrote: I have been considering lending a hand with supporting the effort to port the Xpert98 drivers to DRI. Anyone hear know what is happening in this area? The Xpert98 should be a RagePRO type chipset (if memory serves...)- we're working on a driver right now for that chipset. Just follow the mach64 (the official designation from ATI for all the chips in the Rage/RagePRO family) discussion to get a feel for things. -- Frank Earl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 dma question
On Wednesday 24 October 2001 01:54 am, [EMAIL PROTECTED] wrote: a=readl(kms-reg_aperture+MACH64_BUS_CNTL); writel((a | (31) )(~(16)), kms-reg_aperture+MACH64_BUS_CNTL); same other code works fine. Now why would this be ? This could be caused by the same thing that was giving us fits up until recently. The 4.X XFree86 driver does some things in its init function that override the chip's default settings (ostensibly to improve performance...) that cause at least busmastering for gui operations to not work at all. Do you have to set bits 1 and 2 every time you want a DMA pass or is it just with the first time you do it? -- Frank Earl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: cannot map registers
On Wednesday 24 October 2001 11:30 pm, Gareth Hughes wrote: Hmm, in a day where you can get PC graphics hardware that can run Quake3 at 1600x1200@32 with maximum quality settings at around 100 fps, perhaps you should reevaluate your idea of powerful enough... Now, now, not everybody can use your employer's gear, Gareth... :- (When they come up with something like miniAGP for laptops, I'll be impressed... :-) -- Frank Earl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: Patch to initialize AGP registers
On Saturday 20 October 2001 10:18 pm, Daryll Strauss wrote: On Sat, Oct 20, 2001 at 07:49:56PM +0200, Manuel Teira wrote: OK. Thank you for the clear explanation. Now I think I'm ready to put the new branch in the repository. I'm waiting for the access, guys. As soon as I have access (if i'ts not too late here in Spain) I will proceed. Since I'm going to be working on the actual DMA bits, I'd like to ask for CVS access as well: SourceForge Account: svartalf -- Frank Earl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] ATI Mach64 Driver
On Saturday 21 April 2001 19:44, Jon Pennington wrote: I, too, am interested in the status of this project. It's in the process of being revived. Right now, I'm just seeing what I have to work with. Once I've got a good handle on it, I'll be giving the DMA support another go (which Gareth alludes to...). I have a perfectly good Xpert98 AGP sitting here collecting dust :) I know what you mean. Utah-GLX can deal with many things, but it just doesn't work for XFree86 4.0.X and doesn't quite have the oomph for things like Tribes 2 (which I've seen and played). -- Frank Earl ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] ATI Mach64 Driver
On Friday 20 April 2001 10:36, Markus Kohls wrote: I wonder, if there's anyone working on the mach64-driver yet? After Gareth stopped working on it, there seems to be noone, who is further working on it. Is the development on the mach64 dead? No, it's not dead. Right now as I type this, I'm starting to sort through the process of learning how to get the build process for DRI drivers going. Once I've got that done, I plan on picking up the work done by Gareth followed by Richard Cognot to get RagePRO support under the DRI. -- Frank Earl ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
