Re: Visual artifacts on radeon 9500 dri
Alex Jackson <[email protected]> Wed, 19 Mar 2008 19:29:24 -0400
| Newsgroups | gmane.comp.video.dri.user |
|---|---|
| Message-ID | <[email protected]> |
--===============1093077761== Content-Type: multipart/alternative; boundary="_705f1ecc-a9b6-440c-a9ca-53cbc8a19e6e_" --_705f1ecc-a9b6-440c-a9ca-53cbc8a19e6e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Date: Wed, 19 Mar 2008 18:10:43 -0400 > From: [email protected] > To: [email protected] > CC: [email protected] > Subject: Re: [Dri-users] Visual artifacts on radeon 9500 dri >=20 > On Tue, Mar 18, 2008 at 9:45 AM, Reid Linnemann <[email protected]> wr= ote: > > Written by Alex Deucher on 03/18/08 08:39>> > > > > > > > On Tue, Mar 18, 2008 at 9:02 AM, Reid Linnemann <[email protected]= > wrote: > > >> Written by Alex Deucher on 03/17/08 08:18>> > > >> > On Mon, Mar 17, 2008 at 9:08 AM, Reid Linnemann <[email protected]= e.edu> wrote: > > >> >> Written by Alex Deucher on 03/16/08 19:55>> > > >> >> > On Sun, Mar 16, 2008 at 8:49 PM, Reid Linnemann <[email protected]= state.edu> 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 subs= cribed. > > >> >> >> >> > > >> >> >> >> I'm running Xorg 7.3 with dri on FreeBSD 7-STABLE. > > >> >> >> >> > > >> >> >> >> Some time ago I noticed that seemingly random pixels we= re not being > > >> >> >> >> rendered in all GL contexts, and simply chalked it up t= o my card aging. > > >> >> >> >> But after a while it started to irk me, and then I reme= mbered 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 a= nd 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 mul= tiply/divide, and > > >> >> >> >> overlaid a 16x16 grid. The artifacting lined up perfect= ly in the > > >> >> >> >> checkerboard pattern. I'm now pretty convinced that som= ehow either my > > >> >> >> >> system's DRM module, DRI, or radeon driver are erroneou= sly enabling all > > >> >> >> >> 8 pipelines on the card, resulting in mooky-stink rende= ring. 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 opti= mistic. > > >> >> >> > > > >> >> >> > 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. T= hey just > > >> >> appear as flickering holes in the gl context in the same check= erboard > > >> >> pattern. Does that mean anything to you? > > >> > > > >> > The only valid values for pipe count (bits 3:1) for r3xx chips a= re 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_Regi= sters.pdf > > >> > http://ati.amd.com/developer/open_gpu_documentation/R5xx_Acceler= ation_v1.2.pdf > > >> > > > >> > In your case I suspect you want 0. > > >> > > > >> > Alex > > >> > > >> That was the ticket. Defining R300_GB_TILE_COUNT as 0 in r300_reg.= h > > >> fixed the tiling issue. Huzzah! > > >> > > > > > > Hey, send me your pci ids so I can push the fix upstream. > > > > > > Alex > > > > pciconf -lv output: >=20 > fix pushed to mesa: 65c4ced1ccea7ff88123296b7f0587faa6f23eef Wouldn't it be better, now that we have those register docs, to get the num= ber of working pipes from the card itself (specifically GB_PIPE_SELECT) rat= her than using a list of PCI ids? --AWJ-- _________________________________________________________________ Turn every day into $1000. Learn more at SignInAndWIN.ca http://g.msn.ca/ca55/213= --_705f1ecc-a9b6-440c-a9ca-53cbc8a19e6e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style> .hmmessage P { margin:0px; padding:0px } body.hmmessage { FONT-SIZE: 10pt; FONT-FAMILY:Tahoma } </style> </head> <body class=3D'hmmessage'> > Date: Wed, 19 Mar 2008 18:10:43 -0400<br>> From: alexdeucher@gmail.= com<br>> To: [email protected]<br>> CC: [email protected]= e.net<br>> Subject: Re: [Dri-users] Visual artifacts on radeon 9500 dri<= br>> <br>> On Tue, Mar 18, 2008 at 9:45 AM, Reid Linnemann <lreid@= cs.okstate.edu> wrote:<br>> > Written by Alex Deucher on 03/18/08 = 08:39>><br>> ><br>> ><br>> > > On Tue, Mar 18, 2= 008 at 9:02 AM, Reid Linnemann <[email protected]> wrote:<br>> = > >> Written by Alex Deucher on 03/17/08 08:18>><br>> &g= t; >> > On Mon, Mar 17, 2008 at 9:08 AM, Reid Linnemann <lrei= [email protected]> wrote:<br>> > >> >> Written by Ale= x Deucher on 03/16/08 19:55>><br>> > >> >> > = On Sun, Mar 16, 2008 at 8:49 PM, Reid Linnemann <[email protected]>= ; wrote:<br>> > >> >> >> Jerome Glisse wrote:<br= >> > >> >> >> > On Sat, 15 Mar 2008 11:00:25= -0500<br>> > >> >> >> > Reid Linnemann <= [email protected]> wrote:<br>> > >> >> >> = ><br>> > >> >> >> >> Hi list, this is= my first time posting and I'm not subscribed.<br>> > >> >= > >> >><br>> > >> >> >> >&g= t; I'm running Xorg 7.3 with dri on FreeBSD 7-STABLE.<br>> > >>= ; >> >> >><br>> > >> >> >> = >> Some time ago I noticed that seemingly random pixels were not bei= ng<br>> > >> >> >> >> rendered in all GL = contexts, and simply chalked it up to my card aging.<br>> > >>= >> >> >> But after a while it started to irk me, and = then I remembered something<br>> > >> >> >> >= ;> about my sapphire 9500 - it's got one of the chips with 8 pipelines b= ut<br>> > >> >> >> >> only 4 enabled, pre= sumably a 9700 that didn't pass QA and was rebadged<br>> > >> = >> >> >> as a 9500. At one time this card was on a Win= dows box, and I tried<br>> > >> >> >> >> = enabling all 8 pipelines with the softmod, and got the checkerboard<br>>= > >> >> >> >> pattern that indicated this.<= br>> > >> >> >> >><br>> > >>= >> >> >> With this in mind, I took 10 dumps of a glxg= ears window and merged them<br>> > >> >> >> >= ;> together in a multilayer image in gimp, alternating multiply/divide, = and<br>> > >> >> >> >> overlaid a 16x16 g= rid. The artifacting lined up perfectly in the<br>> > >> >= > >> >> checkerboard pattern. I'm now pretty convinced tha= t somehow either my<br>> > >> >> >> >> sy= stem's DRM module, DRI, or radeon driver are erroneously enabling all<br>&g= t; > >> >> >> >> 8 pipelines on the card, re= sulting in mooky-stink rendering. Anyone have<br>> > >> >&= gt; >> >> any thoughts on this?<br>> > >> >&= gt; >> >><br>> > >> >> >> >>= ; I've attached the images with and without the overlaid grid for reference= .<br>> > >> >> >> >><br>> > >&g= t; >> >> >><br>> > >> >> >>= ><br>> > >> >> >> >>From memory code= which detect card model and decide how many<br>> > >> >&g= t; >> > pipe to enable is wrong for many card. We were just opti= mistic.<br>> > >> >> >> ><br>> > >= > >> >> > Cheers,<br>> > >> >> &g= t;> > Jerome Glisse <[email protected]><br>> > >= ;> >> >><br>> > >> >> >> I'd b= e fine if I knew what code initialized the pipelines, then I might<br>> = > >> >> >> be able to alter it to my needs.<br>>= ; > >> >> >><br>> > >> >> >= <br>> > >> >> > search for R300_GB_TILE_PIPE_COUNT = in r300_state.c<br>> > >> >> ><br>> > >&g= t; >> > Alex<br>> > >> >><br>> > >= > >> FWIW I've tried changing the value of this constant from 3&= lt;<1 (or 6) to<br>> > >> >> 2<<1 (or 4), but= the bad tiles persist - only unrendered to. They just<br>> > >&g= t; >> appear as flickering holes in the gl context in the same chec= kerboard<br>> > >> >> pattern. Does that mean anything= to you?<br>> > >> ><br>> > >> > The only= valid values for pipe count (bits 3:1) for r3xx chips are 0<br>> > = >> > (RV3xx chips - 1 pipe) and 3 (R3xx chips - 2 pipes). The<br= >> > >> > documentation for these chips are available here= :<br>> > >> > http://ati.amd.com/developer/open_gpu_docume= ntation/R3xx_3D_Registers.pdf<br>> > >> > http://ati.amd.c= om/developer/open_gpu_documentation/R5xx_Acceleration_v1.2.pdf<br>> >= >> ><br>> > >> > In your case I suspect you wa= nt 0.<br>> > >> ><br>> > >> > Alex<br>>= ; > >><br>> > >> That was the ticket. Defining R300= _GB_TILE_COUNT as 0 in r300_reg.h<br>> > >> fixed the tiling = issue. Huzzah!<br>> > >><br>> > ><br>> > >= Hey, send me your pci ids so I can push the fix upstream.<br>> > &g= t;<br>> > > Alex<br>> ><br>> > pciconf -lv output:<b= r>> <br>> fix pushed to mesa: 65c4ced1ccea7ff88123296b7f0587faa6f23ee= f<br><br>Wouldn't it be better, now that we have those register docs, to ge= t the number of working pipes from the card itself (specifically GB_PIPE_SE= LECT) rather than using a list of PCI ids?<br><br>--AWJ--<br><br /><hr />Si= gn in and you could WIN! Enter for your chance to win $1000 every day. <a = href=3D'http://g.msn.ca/ca55/216' target=3D'_new'>Visit SignInAndWIN.ca tod= ay to learn more!</a></body> </html>= --_705f1ecc-a9b6-440c-a9ca-53cbc8a19e6e_-- --===============1093077761== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------- 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/ --===============1093077761== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- _______________________________________________ Dri-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-users --===============1093077761==--