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