On Sun, 26 Jun 2005 23:48:11 -0400 Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Sun, 2005-06-26 at 18:05 -0700, Eric Anholt wrote: > > On Mon, 2005-06-27 at 01:19 +0100, Alan Cox wrote: > > > > > Disagree also about axing the comment - its useful to know why something > > > is being done. > > > > Wait, the comment says "TODO: Remove this; we can't afford to let > > userspace control something that locks up the graphics card so easily." > > We're not removing the code being referred to, as far as I've heard, and > > "we can't afford" is contradictory to what we have agreed on for DRI > > policy (drivers can't escalate privelege, but can hang the machine). > > When did this 'agreement' occur? I can't remember agreeing to that. That > we may not be able to prevent all such cases doesn't mean we shouldn't > prevent the ones we can. Without VPU recovery, it is very likely that the prices would be too high to stand. And as long as we dont have that, we dont know how well it works and there is very little point in blocking anything. -4f18 is basicly needed whenever touching Z related registers -4e4c is needed when touching color buffer related registers -2284 is needed before programming vertex programs _and_ maybe before touching VAP registers -different types of 1720's are needed when touching some other regs R300_WAIT_3D | R300_WAIT_3D_CLEAN in r300DoEmitState takes care of mergedfb problems in case someone missed that. As far as iv understood these are needed only if you modify stated after packet3. -- Aapo Tahkola ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
