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 ;) Stephane ------------------------------------------------------------------------------ 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
