On Thu, Feb 19, 2009 at 9:51 AM, Stephane Marchesin <marche...@icps.u-strasbg.fr> wrote: > On Thu, Feb 19, 2009 at 15:46, Alex Deucher <alexdeuc...@gmail.com> wrote: >> On Thu, Feb 19, 2009 at 7:26 AM, Roland Scheidegger >> <srol...@tungstengraphics.com> wrote: >>> On 19.02.2009 12:23, Arkadi Shishlov wrote: >>>> Roland Scheidegger wrote: >>>>> I suspect you're hitting a r200 asic bug, which isn't present in rv250 >>>>> and other r200 family members. There are workarounds in the driver for >>>>> this (see r200UpdateTextureState), but to my knowledge they are >>>>> insufficient for two-pass ATI_fragment_shader shaders. There's also a >>>> >>>> You're right. I changed video card to RV280 9250SE and lockup goes away. >>>> Nice picture, a little slower than fglrx, probably due to 9250 being >>>> slower than 8500. >>> doom3 is actually a performance mystery to me. On my 9000pro, >>> performance seemed to be similar to fglrx, however using another OS it >>> was vastly faster, and I always wondered how it could be tweaked... >>> Hyperz doesn't seem to help much, neither does the mipmap optimization, >>> yet still somehow it must be possible to make it run much faster. >>> >>>> >>>>> mesa test which last I heard showed errors (progs/tests/afsmultiarb) >>>>> (you can switch the test between one and two pass shaders). >>>>> If this is the problem, you could try running doom3 using the arb path I >>>>> think something like doom3 +seta r_renderer arb might work, however arb >>>>> path looks ugly (r_renderer defaults to "best" which will then choose >>>>> "r200" on this card). >>>> >>>> Yes, its ugly and incorrect, some walls are not opaque but blends over >>>> another walls. >>> Oh, that sounds like a bug. Ugly yes but I didn't see that. >>> >>>> >>>>> Unfortunately I don't know how this could be fixed, as documentation for >>>>> these asic bugs is nonexistent (or at least non-public). >>>> >>>> If lockup could be reliable reproduced with simple test - like >>>> afsmultiarb in fresh X without WM - will it be helpfull to get mmio >>>> trace from fglrx and r200 drivers to compare? >>> I think at least some of the asic bugs do not necessarily result in a >>> lockup but also could result in misrendering. Someone might be able to >>> figure out what fglrx does, I guess of particular interest would be the >>> writes to these debug regs (0x2D90 through 0x2DBC). That said, it might >>> not be easy to figure this out completely (could depend on which texture >>> units are enabled in what pass, and depending on filtering on each of >>> those). Or it could even be some completely unrelated bug. >>> >>> >>>> >>>> In the light of recent progress with AMD's attitude, can't you just ask >>>> fglrx guys about R200 bug? >>> R200 is understandably not exactly top priority, and it seemed like the >>> usual docs didn't cover it. Though maybe Alex wants to comment on this. >> >> Unfortunately, r200 is so old, it hard to find much information on it >> anymore. >> > > The r200 docs were released under NDA to selected people. So I don't > think the r200 docs have completely disappeared off the earh ;)
well, we still have those, but those don't seem to cover whatever quirk or errata seems to be at play here. That's the stuff that's hard to dig up. Alex ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
