On Sat, 2 Jul 2005 08:57:17 -0400 (EDT) Vladimir Dergachev <[EMAIL PROTECTED]> wrote:
> >>>> 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. > >> > >> I really mean 'the ones we can'. All I'm saying is that we should try to > >> prevent it whenever reasonably possible and that the fact that it may > >> not always be is IMHO a bad excuse for never trying. > > > > Im looking at the whole picture here. > > I dont really think we have enough manpower and interest of finishing this > > kind of boring task using the most difficult approach available. > > I would like to disagree with you both (Aapo and Michel) :) > > 1. In order to systematically prevent lockups we need to know what lockups > the card is susceptible to. Right now we cannot even find a cause of > particular lockup with Radeon 9800 cards, let alone be certain that any > usage of particular registers is valid. > > We do know which registers control access to system memory and this we > control tightly. > > 2. The issue of making sure no lockups exists will appear a lot less > boring if put in a different context: > > Can we measure how long it takes the card to perform certain > elementary operation and construct a model that would describe performance ? > > This is not a trivial task as we access the card through, essentially, > a batch interface which would make it hard to time elementary > operations by themselves with good precision (say 5% ?). Need to get past Mesas array caches and other funnies. To get to that we need true hw VBO's and we cannot even dream of them until Mesa allows us to support native unsigned char colors. > > Why bother with such project ? > > 1. Characterizing such a complex black-box device is not trivial > and whatever automation techniques will be invented should prove useful > for other things > > 2. Right now we ignore issues like sharing of memory bandwidth with > CRTC or overlay. Knowing timing will allow to fine-tune the raw > performance of the driver. > > 3. It would be interesting to see whether one can do real-time > rendering - not in the sense of playing real-time game, but in the sense > of issuing a drawing operation and knowing exactly when it completes. In advance? If not, scratch regs should take care of this pretty easily. -- 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_id=7477&alloc_id=16492&op=click -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
