On Sun, 18 Jun 2006 14:13:10 +0200 "Jerome Glisse" <[EMAIL PROTECTED]> wrote:
> On 6/18/06, Aapo Tahkola <[EMAIL PROTECTED]> wrote: > > On Sun, 18 Jun 2006 11:58:31 +0200 > > "Jerome Glisse" <[EMAIL PROTECTED]> wrote: > > > > > On 6/18/06, Elie Morisse <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > > > > > I'm keeping an eye on DRM and Mesa CVS commits since 9 months > > > > now, test regularly the whole thing to watch out the fix which > > > > will make my 9800 Pro usable, but nothing at all yet. Are there > > > > particular reasons to that ? What are you missing to make > > > > progress ? > > > > > > > > > > This is far from being easy (at least i find it difficult). We > > > know that we are missing initialization things that fglrx does. I > > > am still testing different part of fglrx initialization but there > > > is about 3Mo of this. More over, some of this lockup the chip as > > > soon as you fire them... > > > > > > So basicly what we are missing is people and time to do this. I > > > have very little time (i am phd student and this already eat up > > > almost all my time). > > > > Have you tried aborting initialization while fglrx is at it? > > That would allow divide and conquer type of approach. > > > > I integrated iba into libsegfault and its working brilliantly. I > > think it should be possible to even put all ring buffer traffic and > > indirect buffers on ignore. > > fglrx initialization is prety fast i would have to put the break > facility in libsegfault. Before trying such things i would like to > test some ram latency things that fglrx does but which lockup the > chip when i mimick fglrx... > > I never used IDA, it's your tools for spying indirect buffer right ? > I should have a look at it :) Is it somewhere ? http://www.rasterburn.org/~aet/libsegfault-iba.tar.bz2 -- Aapo Tahkola -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
