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



-------------------------------------------------------
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

Reply via email to