Re: Visual artifacts on radeon 9500 dri
Roland Scheidegger <[email protected]> Mon, 17 Mar 2008 16:54:12 +0100
| Newsgroups | gmane.comp.video.dri.user |
|---|---|
| Message-ID | <[email protected]> |
Reid Linnemann wrote: > Written by Alex Deucher on 03/17/08 08:18>> >> On Mon, Mar 17, 2008 at 9:08 AM, Reid Linnemann <[email protected]> wrote: >>> Written by Alex Deucher on 03/16/08 19:55>> >>> > On Sun, Mar 16, 2008 at 8:49 PM, Reid Linnemann <[email protected]> wrote: >>> >> Jerome Glisse wrote: >>> >> > On Sat, 15 Mar 2008 11:00:25 -0500 >>> >> > Reid Linnemann <[email protected]> wrote: >>> >> > >>> >> >> Hi list, this is my first time posting and I'm not subscribed. >>> >> >> >>> >> >> I'm running Xorg 7.3 with dri on FreeBSD 7-STABLE. >>> >> >> >>> >> >> Some time ago I noticed that seemingly random pixels were not being >>> >> >> rendered in all GL contexts, and simply chalked it up to my card aging. >>> >> >> But after a while it started to irk me, and then I remembered something >>> >> >> about my sapphire 9500 - it's got one of the chips with 8 pipelines but >>> >> >> only 4 enabled, presumably a 9700 that didn't pass QA and was rebadged >>> >> >> as a 9500. At one time this card was on a Windows box, and I tried >>> >> >> enabling all 8 pipelines with the softmod, and got the checkerboard >>> >> >> pattern that indicated this. >>> >> >> >>> >> >> With this in mind, I took 10 dumps of a glxgears window and merged them >>> >> >> together in a multilayer image in gimp, alternating multiply/divide, and >>> >> >> overlaid a 16x16 grid. The artifacting lined up perfectly in the >>> >> >> checkerboard pattern. I'm now pretty convinced that somehow either my >>> >> >> system's DRM module, DRI, or radeon driver are erroneously enabling all >>> >> >> 8 pipelines on the card, resulting in mooky-stink rendering. Anyone have >>> >> >> any thoughts on this? >>> >> >> >>> >> >> I've attached the images with and without the overlaid grid for reference. >>> >> >> >>> >> >> >>> >> > >>> >> >>From memory code which detect card model and decide how many >>> >> > pipe to enable is wrong for many card. We were just optimistic. >>> >> > >>> >> > Cheers, >>> >> > Jerome Glisse <[email protected]> >>> >> >>> >> I'd be fine if I knew what code initialized the pipelines, then I might >>> >> be able to alter it to my needs. >>> >> >>> > >>> > search for R300_GB_TILE_PIPE_COUNT in r300_state.c >>> > >>> > Alex >>> >>> FWIW I've tried changing the value of this constant from 3<<1 (or 6) to >>> 2<<1 (or 4), but the bad tiles persist - only unrendered to. They just >>> appear as flickering holes in the gl context in the same checkerboard >>> pattern. Does that mean anything to you? >> The only valid values for pipe count (bits 3:1) for r3xx chips are 0 >> (RV3xx chips - 1 pipe) and 3 (R3xx chips - 2 pipes). The >> documentation for these chips are available here: >> http://ati.amd.com/developer/open_gpu_documentation/R3xx_3D_Registers.pdf >> http://ati.amd.com/developer/open_gpu_documentation/R5xx_Acceleration_v1.2.pdf >> >> In your case I suspect you want 0. >> >> Alex > > > Ah, I see. I wondered why the tile pipe count constants were specified > as left-shifted values, I never considered that they were a value in a > bitfield. I'll try that out tonight. > > On further investigation, this really makes sense. Looking at > ati.amd.com, the 9500 isn't even listed in discontinued products - like > they want to pretend it never existed. The 9600, with the rv350 chipset, > has half the pipes of a real r300 chip, and the rv350 tile count value > is 0. I hadn't even considered that. > > Thanks for the help, and for the doc links. This will be good nightstand > reading for a while. If I remember correctly, there was another issue with the r300 chip (and the docs might not tell), it couldn't use hierarchical-z if only 1 pipe was activated due to the way this was coupled to the different pipes. Doesn't look like it gets enabled with the current driver however, so shouldn't be a problem. Roland ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ --