On Mon, 04 Jul 2005 17:12:17 +0100 Keith Whitwell <[EMAIL PROTECTED]> wrote:
> Aapo Tahkola wrote: > > 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. > > Mesa certainly doesn't stop you doing this - you just have to hook it > out at the right level. Well I figured it might actually be good thing since ObjPtr and others point into right place for mapped objects and array cache would provide way to convert this data and pull it to system memory if driver wouldnt support ub colors. > > Things like the array cache are entirely optional - you don't have to > use them in your driver, or not all the time. I havent really crawled myself trought the sources so I dont really know what would be the best way to actually go around this. Not to even mention that I dont really want to read 50000 lines of code to get one feature supported. -- 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
