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
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 Saturday 25 May 2002 06:37 pm, David Willmore wrote: > I'm new to the devel list--I got on to help test the new Mach64 > code. I don't have much time these days to contribute coding, > but I can test. ;) Everything is welcome- and your testing is appreciated. (Nice domain name, BTW. I like it!) > Something struck me while I was watching this thread go on. Since > Linus is on the group, why not ask him how he thinks this could > work? You know, it never dawned on me to do that. I've been going off of what other people have said on the subject- fairly reliable sources (the O'Reilly books on the Kernel operation and device driver development, to be exact...) but not the people working on it on a regular basis. Thanks for mentioning it. Linus, if you're still listening in, can you spare us a moment to tell us what consequences quickly mapping and unmapping memory reigons into userspace has on the system? We've got a couple of the DRM modules that do that to ensure the driver is secure. I'm thinking it's a source of some performance degredation in the drivers and it may not be good on the memory subsytem. -- 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] 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 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 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 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 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: > 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 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
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 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] 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] 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] 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] 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] 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] 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] 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 11:31 am, Leif Delgass wrote: > I know you need to flag the final descriptor at the end of the pass by > setting END_OF_LIST_STATUS in BM_COMMAND (third dword of the descriptor). > In Utah-glx, there's also a series of register writes added to end of the > buffer to "go back to drawing on the front buffer the way the X server > expects." Is this necessary? Utah-glx does this even for pseudo-DMA, but > we don't do this currently. Some of that is not to "go back" but to ensure that things are as close to as they were before execution of the DMA pass. If you reset the control registers to what they were before the GUI master pass, there is no risk of some delayed effect attacks (While there's no risk during a gui-master pass of anything critcal being messed up, there's a slight risk (unverified) that some of the control flags might be acted upon afterwards, messing things up down the line. ). Setting BUS_CNTL and a few select others back to what they were before the pass might not be a bad idea for this stuff. > I was starting to try setting up the descriptor table through the DRM > framework as well, but I'm thinking that this might be the best way to get > started. It might be usable, but it all depends on the smallest size you can allocate that way. I don't know, can the DRM framework allocate 1 16k buffer and then allocate a bunch of 128k or larger ones? If it can't, you don't want to be using that framework for this- you only need 16k aligned on a 16k boundary. -- Frank Earl ___ 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 11:32 am, you wrote: > Regardless of security concerns, the idea was to use this primary buffer > for storing the state update emitted from the DRM. The first entry of > the descriptor table would point to this primary buffer, and the > followings to the client submitted buffer. Anyway, I agree that for the > time being this can stay as MMIO. Yep. > Initially I thought of this too, but since the amount of changes would > be almost the same I preferred to investigate a little further how to do > it definitively. You're wasting memory with that one- all you need is a 16k aligned block for the descriptor table for spaces as large as 2Mb per submission. > Do you think that the interrupt is necessary? Wouldn't it be possible to > use a scratch register for doing buffer aging as it's done in the other > cards? To do things the way I've envisioned them, yes. To do basic DMA with what it sounds like you've got going, no. You'd kind-of need it for detecting the completion of the blit operations and it's nice for periodically checking for a failure in FIFO discipline or a lockup and doing a reset. As for buffer aging, yes, you can do it with a scratch register, but it'll perform MUCH better with doing it with interrupts keeping track of completion. > Could you share with us what you had in mind before? Now that Leif and I > have been studying a little this subject I think we are able to follow > and discuss your ideas. Picture a function that is intended to handle dispatch of DMA-able buffers. It's woke up by a periodic call via interrupt or timer. In this case it's by the VBLANK interrupt. It monitors the current state of affairs (DMA submitted- busy with the same, DMA submitted- completed, etc.) and acts accordingly to handle blocks up to a given size, perform resets of the engine, etc. You have a DMA queue that handles all gui-master operations (Blits are a different story, while I'd love to manage a scheme to queue them up, etc. that works nicely with the gui-mastering operation, writing it up is a lot more complex and may/may not buy us much) as requestors place their requests, they submit a block of operations they wish to do (state info, blank/swap, vertexes to be drawn, etc.) and go on about their way- they really don't need the lock for this since the caller isn't the one managing the DMA pass. When the interrupt wakes up the function, it checks to see if it's supposedly in the middle of a DMA pass or not. If not, it checks the queue and submits up to 1 or 2 Mb of buffers to the DMA. If so, it checks for completion. If the DMA is completed, the function then pushes the used buffers back into the freelist (No keeping track of aging...). If not completed, it increments a timeout counter. If the timeout is reached, it resets the engine and pushes the failed buffers to the freelist. In the design I have in mind, you can have as many requestors submitting DMA requests simultaneously as you want up to the 1-2Mb size range that is realistic for this chip. With it, you know implicitly when something is aged out and could concievably handle throttling of the client easier. The only real sticking point is handling the lock from the DMA function instead of the callers. I was going to hold off on that because it's not obvious how to do it and the code would be needing to wait until the engine was idle anyhow. Right now, I've had another bit of fun keeping me from finishing it earlier this week, but unless more fun comes my way I am still anticpating having something in place that can be looked at if not used by the end of the week. -- Frank Earl ___ 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 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] 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] 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 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 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 Thursday 14 February 2002 10:33 am, Keith Whitwell wrote: > I haven't had a good look at security on either of these cards, but it's > definitely worth doing, both to find out if we're doing too little and if > we're doing too much. I've been looking at the i810 programmer's guide trying to understand why it's acceptable to send commands mixed with the verticies to it (since that is the same boat we're in with the RagePRO), and we might be doing too much in one aspect, and not enough in others. Someone should look over my shoulder here and see if I'm plain flat missing something... While we keep someone from altering the buffer while it's being operated upon by the engine (unmapping the buffer), there is nothing keeping someone from submitting bogus commands to the instruction parser on the chip directly from the user side of things. However, there's the something of the equivalent of user versus kernel space operation with this chip (and we are using it) that keeps the outside world from using it to DMA things, etc. that they're not supposed to so long as you deny them access to the ring buffer. We are doing that, but unfortunately, the driver doesn't seem to use the interrupt framework built into the chip to reset itself after an error has occured (we're using it only to handle DMA flushes in the driver according to comments in the code and my reading of the code in question)- which it has to do to continue operation after a protection violation, according to the programmer's guides. The mapping/unmapping doesn't seem to buy us much in the way of protection and is slow. According to the documentation from Intel, the chip is designed to handle these situations for us. While I know the chip is slow, is it really needed to do this operation which is a very big bottleneck on performance? -- Frank Earl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Pseudo DMA?
On Sunday 10 February 2002 05:08 pm, Gareth Hughes wrote: > How do you prevent a client-side "driver" from sending down blit > commands, without inspecting the DMA buffer? The operations are two distinct beasts with similar interfaces. You can send register/value pairs or tell the engine to blit from system memory to the aperture or from the aperture to the system memory. If the engine is busy handling a gui mastering opertion or a blit operation, I don't think it takes kindly to you yanking it from one mode to another (which would be the only way you could do that...)- I think it'd hang on you. I'd have to try it and see for sure. If it does let you set up and run another DMA pass, then there's a problem- otherwise it's like I said, if you don't allow them to down blit they can't do it. > You can't allow the user-space portion of the driver to fill in > the register programming words in the DMA buffer. Vertex data, > sure, that's okay. The registers are mapped into two separate > pages for PIO access, but all that goes away when you're doing > DMA transfers... The problem is, this chip doesn't accept just verticies like the G400. It wants commands. I'm trying to understand the i810 code since it seems to be the closest situation to my own. It doesn't look like there's a lot of copying there for vertex submissions but yet according to Keith's email earlier today it's got commands in the vertex stream just like this situation. How are they different? (Note that this is not me trying to fob off half-baked stuff here; I'm trying to reconcile the desire for optimal performance with more than a bare semblence of security. That, combined with coming to a complete understanding of what will/won't be acceptable so that the next driver I work on won't take as much time because of learning curve...) I'd like to know why so that it'll all kind-of click. At the time I proposed it, if every one of my assumptions are valid, I would have thought that a defensive mode for the code that does manage a slight chance to crash things would have been a good idea. > Exactly how do you do this? You'd have to set up the buffer with a set of register/value commands that set up a new DMA pass or changed the current one from gui-mastering to blit. Once you'd set that up, you'd have to have to have a descriptor entry that you've munged to point to your code space that blitted from a system area to your area, going through the frame buffer. Or, you'd have to have a bogus descriptor table that performed the same task. In the case of the first possible exploit, that would be nigh-impossible. I do not allow them control or access to the descriptor table for blits or DMA commands- they'd have to have access to the internals of the DRM module (which implies they have more than enough to mess things up anyhow) to use that route. The second route requires memory mapping ability (i.e. John Carmack's memory hack in the RagePRO Utah-GLX driver or the scheme we're using in XFree86 and the DRM) along with the ability to get a 16k aligned page (aligned in bus address space...) and the bus addresses for each and every part of the data space you're using- this would require access at root user levels as well. I could be missing something- that's why I'm discussing it now instead of doing it in a submitted branch and then arguing over it. :-) > It's a damned slow chip. With anything over about a 4-500MHz > processer, you'll still be able to saturate the chip -- we got > it to hit the hardware limit doing PIO with a 600MHz PIII, I > seem to recall... Like I've been saying, I was trying to wring out the last drops of performance out of the card without doing too much of a compromise of things to do it. I guessed wrong on how far I could go- I didn't know, now I do. (Though I partly question the maxing out part- yes, it's a slow chip, but I've not seeing what you're claiming on my end. I've got a PII-450 and it's peak with Utah-GLX was ~250 fps with gears and something like a low 20-ish fps with Q3A. I'm only seeing ~110 fps with the same machine and the PIO hack version of the Mesa driver in the branch. Is a PIII-600 really nearly 2 times faster a machine than the PII-450? :-) And, just because it's a slow chip doesn't mean I should do something else to slow things down further without being absolutely needed. -- Frank Earl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Pseudo DMA?
On Sunday 10 February 2002 04:31 am, Gareth Hughes wrote: > I don't think you should count on being able to reset the chip once > you "detect" a lockup. Things like bus lockups are pretty fatal > events. Besides, I've yet to see the sample code for resetting > the ATI chips actually work reliably, if at all :-) The sample code was missing a piece that we stumbled across. They mention resetting the engine by setting the interrupt on the BUS_CNTL register but then tell you nothing about it. I don't know about bus lockups but the DMA could be reset after it was messed up by doing the extra step. > W.r.t. your first comment, think long and hard about what you could > do with a user-space programmable DMA engine that can read and write > arbitrary locations in system memory. It may be hard, but it's entirely > within the real of possibility that you can become root. The command pathway doesn't seem to allow for that. Only the blit pathway. I've coded only inbound to the aperture writes with that pathway, but not outbound (there's very little that anything other than the X server needs to do that sort of thing). > Similarly, you should not design a mechanism that allows the chip to > lock up for any other reason than a bug in the driver. There is > nothing but "proper" security -- it's either a secure driver, or it's > not. It is unacceptable to have a non-alpha quality driver that has > backdoors like this. Ok, that's going to make the machine do the work twice- once for filling the buffer with verticies and then again to unpack them and submit commands to the engine. I was trying to avoid a bottleneck- but, okay, if that's not acceptable, I'll do it the other way. > Please think about what you're suggesting. These chips can read > and write arbitrary locations in system memory. For all chips that > have this feature, the only safe way to program them is from within > a DRM kernel module. Only clients that have been authenticated via > the usual (X auth) means are able to talk to such modules. There is > simply no other way to do it. You can trust the X server and the > kernel module. You CANNOT trust anything else -- a client-side 3D > driver, something masquerading as one, whatever... The engine doesn't seem to allow for that if you disallow the user to set up blit operations. I'd have to run a test to be sure, but I think the engine would lock up if you messed with the setup registers and tried to transform the gui-master into a blit and that'd be only way what you suggest could happen with the RagePRO from what I can tell. > There is a reason why all the DRI drivers for commodity cards are > designed like this. It's a pain, but that's the price you pay for > a secure system. The other cards seem to mainly have nice pathways for submitting verticies, etc. This one doesn't. I'll recode it to accomodate no commands but pure data- it's not just a pain, it's horribly inefficient with this card the way it's designed. -- 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] Pseudo DMA?
On Thursday 07 February 2002 12:37 pm, Jose Fonseca wrote: > Their glossary (http://utah-glx.sourceforge.net/faq.html#AEN364) gives > the definition of PIO, DMA and Pseudo DMA. PsuedoDMA is pushing the command data in a DMA-able format to an engine that issues PIO commands one-by-one. It's actually slower than doing PIO commands, but allows you to have one pathway for all conditions instead of two differing ways of sending commands to the chip, which makes for easier development in the blocks of code issuing the rendering commands. On a different note, I had some things come up that kept me away from completing the initial cut of the Mach64 DMA code- I should be getting back on track over this weekend and should be building a sub-branch of the Mach64 branch shortly. It will NOT be secure (in the sense that ill-behaved code can't take a box out) for this revision while I work out the details of securing it. Unlike the other chips, apparently there's no distinction between sets of commands such that I can say, "here's a set of verticies, go to it," to the chip, so I either have to come up with a PDMA-ish convention that will degrade performance or come up with some sort of watchdog process inside the module to detect a hang and reset the chip accordingly. (My vote is for seeing if we can come up with a quick check for a locked up state and doing a reset as we now know how to do a full reset that resets the DMA, etc. on the chip from all of our hacking about to get the DMA test working.). -- 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 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 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. Textu
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 locking on mode switches
On Sunday 28 October 2001 03:33 pm, Manuel Teira wrote: > is making WRITE access to the card without calling LOCK_HARDWARE. Perhaps > this funcion is called from another place were the lock takes place, I > don't know. Anyway, when the DMA work takes shape on the Mesa layer, the > places where the lock is needed will be less than now (I think), only when > the DMA buffers are flushed via a BusMaster operation. > So, I think that we must not worry about the interlock while the DMA work > is not finished. That would be my take on things. > Frank, how is it going? Any news? I have started the work. It's taking me longer than I'd originally planned because I'm having to play "find another job quick" as my employer hasn't laid me off and I'm a month and a half past due for paychecks as of Wednesday. I should have the start of something sometime this week, thankfully. -- 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 dma question
On Wednesday 24 October 2001 01:54 am, [EMAIL PROTECTED] wrote: > > a=readl(kms->reg_aperture+MACH64_BUS_CNTL); > writel((a | (3<<1) )&(~(1<<6)), 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 07:17 pm, Carl Busjahn wrote: > Your depth is 24. 3D depths are only 16bit and 32bit. The Mach64 is > really not powerful enough to handle 32bit (which is what 24 yeilds in > XFree86 4.1). I'm not even sure if the driver supports 32bit depth, but > it's not a good idea anyway. Plus you're going to get better overall > quality at 1024x768@16. I can never notice a difference between 16 and > 32 bit, but then, I don't have a ugly nvidia ;-) Actually, it's more than powerful enough- I was running with 32-bit color space when I was testing most of the games out there against the Utah-GLX drivers. Peak perfomance is from 640x480@16 or 640x480@32- anything higher in pixel resolution is accordingly slower. -- 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] Mach64: BusMastering test seems to work
On Friday 19 October 2001 06:13 pm, Manuel Teira wrote: > Well, after some tests, it seems that the problem was caused by the FIFO > size. This was one of the differences between running the little module > (ati_mach64gui.o) under or without X (this is because in the 2D driver, > GUI_CNTL is set to zero when pATI->Chip >= ATI_CHIP_264VT4, in order to use > the max possible fifo depth, 192) . Furthermore, I tested that once X has > run, the DMA test in ati_mach64gui didn't work anymore with or without X > (because the FIFO depth was changed before). > > So, I was able to simulate the same behaviour clearing GUI_CNTL (exactly > the 0 and 1 bits: CMDFIFO_SIZE_MODE, that was set to one by the 2D driver) > in the ati_mach64gui.o. I changed the DRI driver to set the 0 bit in > GUI_CNTL (that is the default value, and, after this, reading GUI_STAT, as > is said in the documentation), and it didn't work. So, I changed some other > things in the DRI driver: set the busmastering in the init function and not > in the bm_test one, removed the call to the dump_engine_info and changed > some register manipulations. After this, the BusMastering test worked and > finally: PAT_REG0=0x !!! This is cool. I've been swamped for quite a bit (this week, I'd not really even had time to pull my e-mail (over 300 messages in my in box...) so I couldn't do much of anything (sorry for the silence gang...). I suspected that this was the problem, but I'd had a problem with the old code that I thought was due to something stupid that I did so I was going to take your newer code and work from that to see if I was right- ran out of personal time on my end (my "employer" has not been making payroll for the past month and half- so I've been doing other things to keep my family afloat...) so I didn't follow up. > I'm attaching the mach64_dma.c in this mail, so anyone can check it in > another machine. I plan on using it to check and do some further cleanups with the 2D driver so that we don't have other "surprises". Thanks for the code. -- Frank Earl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] ATI Rage Pro support
On Tuesday 03 July 2001 10:35, Jens-Peter Konrath wrote: > Is the ATI Rage Pro supported by DRI? Not currently. There is, however, an effort initiated by Manuel Teira to rectify the problem. Right now, the code compiles clean, but doesn't run right. Right now, I'm looking through what he's got that he derived from Gareth's original work to see what I can fix for him. > I noticed that there is a mach64*-branch in the cvs repository. Is it of > any use? Not a lot. It's very old code that's not secure and not bus-mastering. We're using it as a sort of crib-sheet for the in-progress drivers, but it's not terribly useful for end-user purposes. -- Frank Earl ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] ATI Mach64 Driver
On Saturday 21 April 2001 19:48, Gareth Hughes wrote: > Frank, did you ever try the aligned-DMA-descriptors fix? Not yet. I just today found time to get a build started of the stuff Richard Cognot handed me that makes the RagePRO support close to what's in the trunk. As soon as I verify that I have that working, I'm doing that test. Should be shortly. -- Frank Earl ___ Dri-devel mailing list [EMAIL PROTECTED] http://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
