From: Vladimir D. <vo...@mi...> - 2005-07-02 12:57:40
|
>>>> 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% ?). 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. best Vladimir Dergachev > > -- > Aapo Tahkola > |