Same here for Radeon 7500 (RV200 QW). Seems to be happening with only this 
specific chip. The chip seems to mostly be R100 compatible (the R200 code path 
does not work at all).

Glitches on e.g. with Bitstream Vera Sans Mono in konsole.
I also noticed glitches in several applications with smooth scrolling. As soon 
as you scroll a pixel at a time, the new lines are sometimes distorted. Often 
this does not happen, when you scroll larger chunks.

Seems to be specific for the R100 rendering path, not for the chip. I get the 
same distortions for a R100 QD (Radeon 7200).

I can confirm this bug as well. I am running X.org 6.8.0 also from Gentoo
e-build.    My applicable hardware is: ATI Technologies Inc Radeon Mobility M7
LW [Radeon Mobility 7500]

Ok, more info (just that so this is not lost):

It seems that the GPU does not fetch the new texture but uses its texture cache
until a sufficiently large (whatever that is) primitive is rendered.

I added a texture buffer ring so that no consecutive textures are stored into 
the same part of the video memory - with no effect.

I increased the minimum loaded texture size to 64x64 - with no effect.

I increased the minimum *drawn* texture to 64x8 -> everything looks all right!

Unfortunately, this is no solution, as the render system just has to be able to 
draw smaller parts of the texture. E.g. if I fix it for scrolling up (which I 
did by adding transparent lines below the current texture), I cannot use the 
same texture for scrolling down. And even if I fix both, it is possible that 
only a small span of the middle of the texture has to be rendered.

Two possible sollutions:
a) There must be some command like 'fetch the texture. do it now.'
b) For small textures draw a large version into a off-screen frame buffer before 
using it. This may sound horribly complicated or slow, but it shouldn't be.
However, the size of the texture that has to be drawn is some magic constant..

Created attachment 1209 [details] [review]
[FIXED_X11R68x] Patch for pre-rendering small textures for Render Acceleration on R100

This patch adds pre-rendering of small textures to the R100 code path. They are

rendered to off-screen memory in order to invalidate the texture cache.

Note that this has to be dicussed before inclusion into mainline, because it
still is some sort of hack. The correct way to deal with the situation would be
to invalidate the texture cache without rendering large texture splats. If
anybody knows how to do this on R100, please respond!

The performance hit is measurable, but text output is still much faster than
w/o using RenderAccel, even for small regions (e.g. single chars).
Performance meassurement pending.

Note that the code relys on magic constants (in the top of the source) that
need to be verified, as they might depend on too many constraints for me to
test them all. So far verified with RV200 on 1024x768 with 2 different CPUs.

Please test, and if you still encounter glitches, feel free to change the
constants and add your values to this bugzilla entry.

Created attachment 1210 [details] [review]
Patch for x11perf to perform single character output tests

Performance results:

				   RV200/PII@400MHz   RV200/AMD64@2000Mhz
x11perf -rgbftext (80 chars output)
  RenderAccel w/o Patch 		80.900/s	   345.000/s
  RenderAccel w/ Patch			80.900/s	   345.000/s
  w/o RenderAccel			16.200/s	    37.400/s
x11perf -srgbftext (singel char output)
  RenderAccel w/o Patch 		10.200/s	    65.200/s
  RenderAccel w/ Patch			 9.450/s	    54.300/s
  w/o RenderAccel			 8.500/s	    31.100/s

So we get a perfomance loss of 20% in the worst case on the fast machine, which

is not too bad thinking about what I have to do here...
We still get the full speedup for large rendering areas, and that is where 
RenderAccel really shines =)

Seems that I do not understand this bugzilla config correctly - wanted to
accept the bug, but it is still assigned to xorg-bugzilla-noise. Sigh.

Any comments so far?

Have you tried adding a RADEON_FLUSH_CACHE() and maybe a
RADEON_WAIT_UNTIL_IDLE() to R100SetupTexture? This is what the drm module does
when uploading textures. It seems more related to texture blit though as far as
I can see, but it might be worth a try.
(briefly looking at the code, I'm wondering why r100 uses linear filtering, but
r200 uses nearest. Doesn't look to be related though...)

I tried RADEON_WAIT_UNITL_IDLE but seem to just have missed the
RADEON_FLUSH_CACHE... I'll try, thanks!

I found that bilinear vs. nearest neighbor thing as well (especially the DMA and
IO routines differ here as well!), and fixed that in my local sources, but
forgot that fix.

Stupid me that I overlooked those...

However, even a PURGE followed by a WAIT_IDLE as in

    OUT_ACCEL_REG(RADEON_RB2D_DSTCACHE_CTLSTAT, RADEON_RB2D_DC_FLUSH_ALL);
    OUT_ACCEL_REG(RADEON_WAIT_UNTIL, RADEON_WAIT_2D_IDLECLEAN |
RADEON_WAIT_3D_IDLECLEAN | RADEON_WAIT_HOST_IDLECLEAN);

does not help. The patterns only go away if pre-rendering is active. I do not
see any further possibilities to flush the cache, but then I didn't noice this
one either :-/

Where and how exactly did you add the purge? Do you have a patch for that?

No, I don't have a patch for that right now (could create one, though). I added
the two lines above immedeately after texture setup (both routines) and addapted
the BEGIN_ACCEL() sizes.

Created attachment 1427 [details] [review]
Non-working patch using purge+wait only

This is the patch using purge + wait after texture initialization. This does
NOT fix the rendering artifacts.

Created attachment 1428 [details] [review]
Non-working patch using even more purge+wait

Doing even more purge + wait. Still, we do not get rid of the artifacts.

Well, the EngineFlush and WaitForFifo certainly don't make sense there, at least
not with DRI enabled. I guess it doesn't make a difference either if you put the
register writes right after the BEGIN_ACCEL()?

Created attachment 1429 [details] [review]
Non-working patch, purge+wait moved to begin of ring output

I agree that these calls don't make sense, I just added everything I could
imagine to rule out subtle side effects.

No, it does not make any difference to move the flush at the begin of the ring
command set.

Render acceleration is really relevant to get decend performance for anti
aliased font rendering etc. Therefore this issue should be addressed. It is sad
that we don't see a resolution here. Unless we get help to find a better
solution we need the workaround that Matthias suggests.

I don't know if the patch that Matthias created was committed to CVS or not, but
with Xorg 6.8.2RC1 the artifacts have disappeared, at least for me.

Can anyone else confirm this? 

I still can notice them with RC1.

Incidentally, has anybody tried whether this still occurs (or whether RENDER
acceleration still works at all...) with current HEAD, which uses DMA for
transferring the RENDER texture data to the framebuffer?

(In reply to comment #18)
> I still can notice them with RC1.

Incidently, I did notice some artifacts shortly after I submitted the comment :(

However, they seem very rare (mostly appearing is applications like
OpenOffice.org; GTK and QT apps are less prone to these glitches). I am running
6.8.2RC2 now and haven't noticed any today. This is certainly an improvement,
even without Matthias's patch.

I've tried applying Matthias's patch, and I noticed that while there is no
performance impact during normal use, running xcompmgr is _really slow_.
Scrolling lags by ~1 second in full-screen windows, and windows move in steps.

Fortunately, xcompmgr seems to eliminate most of the glitches, so the moral of
the story is to use either the patch or xcompmgr but not both. We just need to
make sure the patch can be disabled if it ever gets commited. 

Overall though, I would recommend trying the 6.8.2RC2 release to eliminate many
font glitches and xcompmgr bugs.

I assume that it still apears in pre 6.8.2. We should consider applying the
patch there.
Also someone should test if it also exists in HEAD - since the driver has been
modified considerably.
I'll nominate the patch for 6.8.2.

I wanted to test this on Friday, but currently building static Xservers seems to
be broken.
This is currently discussed on xorg.

AFAI can see the bug should still show up. There is no code change in the driver
that could make a difference here. I want to test the slowdown Anton has
reported as well, as I do not understand them. xcompmgr should work with rather
large textures, so it shouldn't be affected by the patch at all!

(In reply to comment #22)
> I wanted to test this on Friday, but currently building static Xservers seems to
> be broken.

Try a non-static server then? :) You can even build the HEAD driver against an
otherwise 6.8 tree and try that.

> AFAI can see the bug should still show up. There is no code change in the driver
> that could make a difference here. 

It only uses a completely different method for uploading the texture data... ;)
(with DRI enabled)

> I want to test the slowdown Anton has reported as well, as I do not understand
> them. xcompmgr should work with rather large textures, so it shouldn't be
> affected by the patch at all!

Well, your patch does increase the bandwidth usage by an amount that corresponds
to the texture size, doesn't it? Then again, xcompmgr is slow even without the
patch due to shortcomings in XAA.

> > I wanted to test this on Friday, but currently building static Xservers seems to
> > be broken.
> Try a non-static server then? :) You can even build the HEAD driver against an
> otherwise 6.8 tree and try that.

Ok, but I wanted to debug a bit and that is rather - err - wearisome to
do with a dynamic one. Also there are a couple of other things to do here as well ;)

> > AFAI can see the bug should still show up. There is no code change in the driver
> > that could make a difference here. 
> It only uses a completely different method for uploading the texture data... ;)
> (with DRI enabled)

The bug showed up with and w/o DRI enabled. So at least in one case it
should still be present. But you're right, I somehow overlooked the texture upload.

> > I want to test the slowdown Anton has reported as well, as I do not understand
> > them. xcompmgr should work with rather large textures, so it shouldn't be
> > affected by the patch at all!
> 
> Well, your patch does increase the bandwidth usage by an amount that corresponds
> to the texture size, doesn't it? Then again, xcompmgr is slow even without the

Only if the patch to be rendered is small enough (TM).

Ok, tested it a bit, and with DRI enabled the next texture loading method seems
to work fine. So - as far as I am concerned - the patch is not necessary in that
case. Thanks, Michael!

w/o DRI the rendering bug still shows up. Michael, is the new texture uploading
routine usable without DRI as well, or shall I adapt my patch for the non-DRI
case only?

Anton, can you verify that you still get any glitches, and if this is the case
verify that you have DRI enabled?

You're welcome, Matthias, even though you (like so many others before) didn't
spell my name correctly. ;)

Glad to hear the new upload method works fine. Hostdata blits could also be used
with DRI disabled, I'm not sure how that will perform, but I hope it won't be
worse than the workaround.

Matthias' workaround should probably be applied to the 6.8 branch only for now?

> You're welcome, Matthias, even though you (like so many others before) didn't
> spell my name correctly. ;)

*Blush*
I should know because I'm written in the wrong way often as well. How embarrassing.

> Glad to hear the new upload method works fine. Hostdata blits could also be used
> with DRI disabled, I'm not sure how that will perform, but I hope it won't be
> worse than the workaround.

I guess it won't ;)

> Matthias' workaround should probably be applied to the 6.8 branch only for now?

Actually I would opt for changing the driver in 6.8.2. This seems to be stable
and I'm not really happy with my workaround either.
Having glitches w/ DRI disabled (but RenderAccel enabled, strange combination)
is not too problematic I think, so changing this code path can be something for
CVS head only.

After a discussion with Egbert:

As it seems we don't get the new driver with DMA texture upload into 6.8.2. In
this case I would opt for inclusion of this patch into 6.8.2. It reduces
performance of render, but it is not really useable w/o.

I have to check it against xcompmgr, and if I find the same drawbacks as Anton,
I might have to add a switch to turn it off. Maybe I can find out why it slows
down rendering (it shouldn't in this case). I'll do this tomorrow.

I was asked, why I calculate the size of the off-screen render area by
pScrn->displayWidth * MAGIC_R100_MIN_TEX_HEIGHT: I didn't want to alter
destination pitch for predraw, so the off-screen area has to be larger than the
chunk that is actually drawn.

Comment on attachment 1209 [details] [review]
[FIXED_X11R68x] Patch for pre-rendering small textures for Render Acceleration on R100

I am going to push this patch into the upcoming release canidate to get more
extensive testing. We can still rip it out if it causes any problems (and there
is always the option to disable renderaccel as workaround on the customer side)
...

We've (keithp and myself) found the issue while working on Xati's render
acceleration today, it seems.  RB2D_DSTCACHE_* are actually read-only mirrors of
RB3D_DSTCACHE_*.  Writing to them has no effect, at least on some chipsets.  The
solution is to swap RB2D_DSTCACHE_CTLSTAT for RB3D_DSTCACHE_CTLSTAT (0x325C
instead of 0x342c), so that the flushes actually happen.  I ought to review the
x.org code again to look for other issues, but this is probably the root of it.
 My speculation as to why DRI and everything else has worked using the same
flushing technique that autoflushing makes reads usually work, and hostdata
blits (used normally for uploading stuff) keep the cache coherent and don't need
the flushing, but our usage of memcpy followed by reading from that memory
breaks for some people.

Comment on attachment 1209 [details] [review]
[FIXED_X11R68x] Patch for pre-rendering small textures for Render Acceleration on R100

Patch checked-in into X11R6.8.x stable branch:
/cvs/xorg/xc/ChangeLog,v  <--  ChangeLog
new revision: 1.365.2.137; previous revision: 1.365.2.136
cvs commit: Using deprecated info format strings.  Convert your scripts to use
the new argument format and remove '1's from your info file format strings.
/cvs/xorg/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon.h,v  <--  radeon.h
new revision: 1.8.2.1; previous revision: 1.8
/cvs/xorg/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_render.c,v	<-- 
radeon_render.c
new revision: 1.8.2.1; previous revision: 1.8
cvs commit: Using deprecated info format strings.  Convert your scripts to use
the new argument format and remove '1's from your info file format strings.
Mailing the commit message to xorg-commit@lists.freedesktop.org...

Lets hope this doesn't cause any new problems... ;-/

Eric, Keith,

just tried out to substitute RB2D_DSTCACHE_CTLSTAT with RB3D_DSTCACHE_CTLSTAT.
So far no change in the behaviour. However, I'm not entirely sure that my code
is correct, as I still set RADEON_RB2D_DC_FLUSH_ALL (not 3D) as I have no
reference for the correct codes.
Sorry, folks, but this does not seem to remove the glitches. Only using DMA like
in the cvs HEAD seems to work.

(In reply to comment #25)
> Ok, tested it a bit, and with DRI enabled the next texture loading method seems
> to work fine. So - as far as I am concerned - the patch is not necessary in that
> case. Thanks, Michael!
> 
> w/o DRI the rendering bug still shows up. Michael, is the new texture uploading
> routine usable without DRI as well, or shall I adapt my patch for the non-DRI
> case only?
> 
> Anton, can you verify that you still get any glitches, and if this is the case
> verify that you have DRI enabled?

Well, I haven't seen any of the glitches since I started using 6.8.2-rc2. 

Also, the slowdown with xcompmgr is gone in 6.8.3-rc3 (which has Roland's
patch). I actually think it was something I did, or something with my system.

I think the main xcompmgr slowdowns I saw were related to the new 0/1 scheduler
in the 2.6 kernel (once the X server started hogging resources, the scheduler
gave it lower priority). By setting the X server (and xcompmgr) priority to '-5'
as opposed to the recommended '0' on 2.6 kernels, I get very decent xcompmgr
performance on my R100 (without fading windows).

Anyways, I've tried it with HEAD, and I didn't notice any difference with
performance or visually. Is there anything special I have to do to enable the
new DRI texture uploads? glxinfo shows "direct rendering: Yes". 'glxgears' still
gives me the same framerate, if that is an indicator.

(In reply to comment #33)
> (In reply to comment #25)
> 
> Also, the slowdown with xcompmgr is gone in 6.8.3-rc3 (which has Roland's
> patch). I actually think it was something I did, or something with my system.

In my experience, compositing sometimes suddenly becomes much slower and never
seems to recover. Could be some video memory management issue or something. Or
maybe the process scheduling, as you suggested.


> Anyways, I've tried it with HEAD, and I didn't notice any difference with
> performance or visually. 

Bummer. The change certainly had a significant effect on x11perf -aa{10,24}text
numbers here, and it also seemed to improve compositing, but maybe that's just me.

> Is there anything special I have to do to enable the new DRI texture uploads?
> glxinfo shows "direct rendering: Yes". 

In that case, the new code is active.

> 'glxgears' still gives me the same framerate, if that is an indicator.

No, the change only affects Render acceleration, not OpenGL.

(In reply to comment #34)
> (In reply to comment #33)
> > Anyways, I've tried it with HEAD, and I didn't notice any difference with
> > performance or visually. 
> 
> Bummer. The change certainly had a significant effect on x11perf -aa{10,24}text
> numbers here, and it also seemed to improve compositing, but maybe that's just 
> me.

Ah, now I see the improvements; it's not so much the speed but the
responsiveness for me. Now I can move a window with xcompmgr running, and not
have it interrupt an MP3 playing in the background. I don't even have to change
the X server priority like I mentioned earlier. I guess it's because the DMA
transfers free up the CPU.

Great job!

(In reply to comment #33)
> Well, I haven't seen any of the glitches since I started using 6.8.2-rc2. 

Well, then I assume DMA texture upload does fix this entirely. Good news.

> I think the main xcompmgr slowdowns I saw were related to the new 0/1 scheduler
> in the 2.6 kernel (once the X server started hogging resources, the scheduler
> gave it lower priority). By setting the X server (and xcompmgr) priority to '-5'
> as opposed to the recommended '0' on 2.6 kernels, I get very decent xcompmgr
> performance on my R100 (without fading windows).

Sounds reasonable. xcompmgr works with large texture chunks, they should never
ever trigger my workaround.

Michel, if we get DMA for the non-DRI case as well, I won't bother rewriting my
patch to this case. No need to hurry, though, I just want to schedule my work.

(In reply to comment #36)
> (In reply to comment #33)
> > Well, I haven't seen any of the glitches since I started using 6.8.2-rc2. 
> 
> Well, then I assume DMA texture upload does fix this entirely. Good news.

The 6.8 branch still doesn't have the DMA upload, does it?


> Michel, if we get DMA for the non-DRI case as well, I won't bother rewriting my
> patch to this case. No need to hurry, though, I just want to schedule my work.

I do plan to play with using hostdata blits (note that DMA isn't possible
without kernel support) without DRI, but I don't know when I'll get around to
it, so feel free to beat me to it everybody.

I'm sorry, I can still notice the problem with Ximian Openoffice and xorg 6.8.2
RC4 (http://ghepeu.altervista.org/immagini/font-problem.jpg), specially with
letter "i". With other applications everything seems to be working.

I've just installed latest CVS DRI drivers and this is what I could notice:

1) in first X server (the one with direct rendering enabled) I can see bad
rendering of some type 1 fonts (similar to
http://ghepeu.altervista.org/immagini/fuffa/font-no2.jpg) but there aren't
anymore glitches like these ones
(http://ghepeu.altervista.org/immagini/fuffa/font-no.jpg)

2) glitches (like the ones in the screenshot in my comment #38) are still
present when direct rendering is disabled (for example in second X server launched)



PS. I compiled 20050207 CVS and the files I installed are:

radeon_dri.so
ati_drv.so
radeon_drv.so
libdrm.so
libdri.so
libGLcore.so
libGL.so.1.2

I couldn't get working openGL with new libglx.so

(In reply to comment #39)
> 
> 1) in first X server (the one with direct rendering enabled) I can see bad
> rendering of some type 1 fonts (similar to
> http://ghepeu.altervista.org/immagini/fuffa/font-no2.jpg)

I'm afraid I don't see the issue, even with the arrows... does this go away if
you disable RENDER acceleration? If not, it's not related to this bug.

Hello,    
    
I got the same problems, the font rendering glitches but also something that    
looked like a "bandwidth memory" problem. Kinda high frequency waves all over    
the screen, specially when a lot of repainting happens (like scrolling large    
text view)    
    
However, with 6.8.2 the font render glitches are indeed gone, allas the  
"bandwith    
memory" render glitches aren't.    
    
I disabled both DRI and put Option "RenderAccel" "Off" in my xorg.conf and the   
problem is almost gone. Only on very heavy redrawing activities (Kontact   
splitter moving for example does this very very heavily) there are still some   
small rendering glitches visable (just all over the screen).   
   
Unfortunately, I can't show a screenshot of this problem, seems screenshots are   
rendered offscreen?   
   
As soon as I enable DRI and "RenderAccel" the problem is back again :-(   
Hopefully you can find out the problem sooner or later....   
   
Thanks,   
   
Remon   

(In reply to comment #41)
>     
> I got the same problems, the font rendering glitches but also something that    
> looked like a "bandwidth memory" problem. Kinda high frequency waves all over    
> the screen, specially when a lot of repainting happens (like scrolling large    
> text view)    
>     
> However, with 6.8.2 the font render glitches are indeed gone, allas the  
> "bandwith memory" render glitches aren't.    

Please don't hijack an existing bug for a different issue but create a new one
if necessary. Does

    Option "DisplayPriority" "HIGH"

fix this problem?

Sorry if I hijacked this bug report, but after reading this thread I got the 
assumption it was the same problem, but only worse on my PC. 
If you want me to file a seperate bug report for this issue? 
 
Unfortunately, setting display prio to "high" doesn't make any difference :-( 
 
Remon 

(In reply to comment #41)
> I got the same problems, the font rendering glitches but also something that    
> looked like a "bandwidth memory" problem. Kinda high frequency waves all over    
> the screen, specially when a lot of repainting happens (like scrolling large    
> text view)    
> [...]
> Unfortunately, I can't show a screenshot of this problem, seems screenshots are   
> rendered offscreen?   

This sounds very much like a hardware problem (presumably your ramdac/memory
interface interferes with other regular memory accesses). If nobody else
exhibits this effect, I assume it is broken hardware.

Michel might have other / more information on the topic, though. I would rather
listen to him than to me ;^)

I've been looking into this issue recently, and have found out a few interesting
things.  The pre-rendering workaround patch does not solve the problems that I'm
seeing on my R100s and RV200s.  However, I found that I could work around the
problem in one of two ways: either change the PP_TEX_SIZE_0 from "(height-1)<<16
| (width-1)" to "height<<16 | width", or force the code to never use
non-power-of-2 textures and fix the dst_pitch to always be a power of 2 (instead
of just a multiple of 32).  Neither of these changes are required for R200 and
newer chips.

I'll attach a patch next that works around the problems for me.

Created attachment 2178 [details] [review]
Workaround for R100/RV200 font rendering problems for 6.8.2 branch

Could those who are seeing the font rendering problem please test this patch to
see if it fixes them and report back here?  This patch is against the 6.8.2
release.

Interesting, but then I wonder why HEAD works for Matthias without this (or any
other, for that matter) workaround; is that the case for you too, Kevin?

now I'm using CVS driver (compiled as explained in this page:
http://dri.freedesktop.org/wiki/Building) with 6.8.2 release, but I still notice
the old problems when direct rendering isn't enabled (running a second X server,
for example) and sometime minor glitches, for example vertical 1-pixel wide
lines on the left side of letters. I'm going to check this patch as soon as
possible.

When DRI is not enabled the HEAD branch still uses the old texture upload
approach, while it uses a DMA based one when DRI is enabled. Eventually, both
code paths will use DMA, so we only would need an intermediate fix.

I think that R100 had several hardware flaws (race conditions and undealt
exceptions) that have to be worked around. This is difficult to do without
errata sheets, and I doubt that these even exist for graphics hardware (the
release cycle is too fast paced for decent chip specific documentation). You
typically only get those sheets for products with a long livetime or for
products that are integrated a large number of companies.

well, I applied the patch to HEAD radeon_render.c (just the hunks that were
applicable) but the result is worse than actual behavior:
http://ghepeu.altervista.org/xorg/firefox.jpg
http://ghepeu.altervista.org/xorg/gnome-menu.jpg
http://ghepeu.altervista.org/xorg/oo.jpg
http://ghepeu.altervista.org/xorg/terminal.jpg

some of these glitches disappear if I move the mouse over, others appear randomly.

(In reply to comment #50)
> well, I applied the patch to HEAD radeon_render.c (just the hunks that were
> applicable) but the result is worse than actual behavior:

Applying the patch to HEAD should definitely fail and will cause problems.  The
patch is only for the 6.8 branch.

FYI, this patch fixes the 1-pixel wide vertical lines that appear on my R100 and
RV200 cards in 6.8.2.

(In reply to comment #47)
> Interesting, but then I wonder why HEAD works for Matthias without this (or any
> other, for that matter) workaround; is that the case for you too, Kevin?

Hi Michel, I'm building HEAD right now and should be able to let you know in a
little while if the DRI-enabled case works without any patches.

(in reply to comment #51)
>Applying the patch to HEAD should definitely fail and will cause problems.  The
>patch is only for the 6.8 branch.

Oh, I understand

>FYI, this patch fixes the 1-pixel wide vertical lines that appear on my R100
>and RV200 cards in 6.8.2.

with HEAD I still have problem of this kind:
http://ghepeu.altervista.org/xorg/minor-glitch.jpg

(In reply to comment #49)
> I think that R100 had several hardware flaws (race conditions and undealt
> exceptions) that have to be worked around. This is difficult to do without
> errata sheets, and I doubt that these even exist for graphics hardware (the
> release cycle is too fast paced for decent chip specific documentation). You
> typically only get those sheets for products with a long livetime or for
> products that are integrated a large number of companies.

I tend to agree that there are several problems here since the pre-rendering
workaround patch that fixed the problem for you, didn't help in my case, but the
two workarounds that I found, worked fine.

Matthias, could you try my patch on a 6.8.2 build using the hardware that worked
with your pre-rendering patch?  My patch #if 0's the pre-rendering part out, so
this should give us a good indication if we are seeing one or two problems.  You
might also want to try to force the code to use the non-power-of-2 code since
that code path also works for me with my patch.

(In reply to comment #53)
> with HEAD I still have problem of this kind:
> http://ghepeu.altervista.org/xorg/minor-glitch.jpg

That looks like what I've been seeing on the 6.8 branch.  I'm building HEAD
right now.  Once that finishes, I'll try it to see if we're encountering the
same problem and try to come up with a workaround.

(In reply to comment #55)
> (In reply to comment #53)
> > with HEAD I still have problem of this kind:
> > http://ghepeu.altervista.org/xorg/minor-glitch.jpg
> 
> That looks like what I've been seeing on the 6.8 branch.  I'm building HEAD
> right now.  Once that finishes, I'll try it to see if we're encountering the
> same problem and try to come up with a workaround.

Okay, I've built HEAD, and it still has the same problem as reported above.  If
I just change the tex_size from my previous patch, HEAD works fine.  I'll attach
a patch next.  However, my other solution to use only power of 2 textures didn't
work -- my assumption there is that it has to do with the tiling changes that
are in HEAD.

Created attachment 2186 [details] [review]
Workaround for R100/RV200 font rendering problems on HEAD

Giacomo, could you try this patch on HEAD?
It appears to solve the problem that I'm seeing on HEAD.

Okay, the tex_size fix seems correct then.

(In reply to comment #58)
> Okay, the tex_size fix seems correct then.

I agree this fix works around one bug, but I'm concerned that there are actually
two bugs.  One fixed by the tex_size change and one fixed by the pre-rendering
texture change that Matthias made.  I'm curious if both fixes are needed, or
just one.  I'd like to hear from anyone that had their problem fixed by
Matthias' patch whether or not my patch also fixes their problem on the 6.8.2
branch (since I disabled his fix in my first patch).

(In reply to comment #57)
> Workaround for R100/RV200 font rendering problems on HEAD
> 
> Giacomo, could you try this patch on HEAD?
> It appears to solve the problem that I'm seeing on HEAD.
> 

Finally I have got a free afternoon, so I compiled HEAD with this patch, I
tested the system for an hour and as far as I can tell the glitches I was
experiencing before are gone, with both direct rendering enabled and disabled.
The only exception is openoffice-ximian, but as matters stand I think this is a
bug in their code.

After a week I can say that this patch fixes all glitches and I've just noticed
that it fixed my problems with Type1 fonts' rendering too, I suggest inclusion
in both 6.8.x and HEAD branches.

> I'm concerned that there are actually two bugs.  One fixed by the tex_size 
> change and one fixed by the pre-rendering texture change that Matthias made.

my opinion: it seems that most glitches used to appear on the right side of the
rectangle in which letters are included. maybe Matthias patch by pre-rendering
small textures simply reduced the frequency of glitches so they were often
unnoticed?

mass update: this bug was applied to the stable 6.8 branch but NOT to HEAD!

Sorry, been busy for a while...

Kevin, if I read your patch in attachment 2178 [details] [review] correctly, this one disables my
patch but changes the texture size to 2^n *instead*. Am I right?
Does this (together with the width/height setup) fix all problems? Then we might
have stumbled over an alignment problem, and it could be enough to just use
texture widths that are multiples of 8, 16 or 32. Maybe texture heights have to
be equivalent, maybe not.

I'll do some tests.

> my opinion: it seems that most glitches used to appear on the right side of the
> rectangle in which letters are included. maybe Matthias patch by pre-rendering
> small textures simply reduced the frequency of glitches so they were often
> unnoticed?

Could well be. That would perfectly make sense with my assumption above.

(In reply to comment #63)
> Sorry, been busy for a while...
> 
> Kevin, if I read your patch in attachment 2178 [details] [review] [edit] correctly, this one
disables my
> patch but changes the texture size to 2^n *instead*. Am I right?

Partially correct.  It does disable your patch, but the texture size is actually
set to max(32,2^ceil(log2(width))).  Basically, it's just rounding the dst_pitch
up to the next power of two that completely contains the texture but makes sure
that the pitch is at least 32.

> Does this (together with the width/height setup) fix all problems? Then we might
> have stumbled over an alignment problem, and it could be enough to just use
> texture widths that are multiples of 8, 16 or 32. Maybe texture heights have to
> be equivalent, maybe not.

I had troubles with pitches less than 32, so that was why I made the minimum
texture width 32.  However, note that this was just for the second solution to
the problem (see comment #45 for details).  The first solution is the change to
tex_size = (height << 16) | width; which is the code path that is taken most
(all?) of the time.

Maybe I'm trying to explain too much in this patch.  I'll create two different
patches, each with their own solution.  That should help make the two different
solutions clearer.

(In reply to comment #64)
> > Kevin, if I read your patch in attachment 2178 [details] [review] [edit] [edit] correctly, this one
> disables my
> > patch but changes the texture size to 2^n *instead*. Am I right?
> 
> Partially correct.  It does disable your patch, but the texture size is actually
> set to max(32,2^ceil(log2(width))).  Basically, it's just rounding the dst_pitch
> up to the next power of two that completely contains the texture but makes sure
> that the pitch is at least 32.

Right. Ok, just wanted to make sure that prerendering is disabled with your patch.

> I had troubles with pitches less than 32, so that was why I made the minimum
> texture width 32.  However, note that this was just for the second solution to
> the problem (see comment #45 for details).  The first solution is the change to
> tex_size = (height << 16) | width; which is the code path that is taken most
> (all?) of the time.

I think we're safe to assume there have been 2 problems.

> Maybe I'm trying to explain too much in this patch.  I'll create two different
> patches, each with their own solution.  That should help make the two different
> solutions clearer.

No need, I think this is clear now.
I'll try your patch and a aligned non-power-of-2 patch. I'll let all of you know
about the outcome.

Created attachment 2314 [details] [review]
Solution #1 for R100/RV200 font rendering on 6.8 branch

It was trivial to do, so I went ahead and broke the two solutions out into
separate patches for the 6.8 branch.

Created attachment 2315 [details] [review]
Solution #2 for R100/RV200 font rendering on 6.8 branch

This one uses the alternate rendering path.

(In reply to comment #65)
> (In reply to comment #64)
> > I had troubles with pitches less than 32, so that was why I made the minimum
> > texture width 32.  However, note that this was just for the second solution to
> > the problem (see comment #45 for details).  The first solution is the change to
> > tex_size = (height << 16) | width; which is the code path that is taken most
> > (all?) of the time.
> 
> I think we're safe to assume there have been 2 problems.

That's my assumption as well.  If either of my patches don't solve the problem
you're seeing, then I think that confirms we have 2 separate problems.

I'm currently having troubles reproducing the rendering problem. It is the same
hardware, I just installled a SL9.3 beta on it, and everything (almost) seems
fine. I just got some very small rendering artifacts, but that occure with any
set of patches, and they could very well be gtk or general Xserver related.

I'll try a fresh install of 9.2 on this machine and test again.

Ok, I got it reproduced. Only SL9.2 only, but the same Xserver binary. Have to
verify it with SL9.3, maybe the qt libraries changed font rendering a bit.

1) Attachment 2314 [details] shows rendering glitches.
2) Attachment 2315 [details] shows rendering glitches as well.

So *I* do not see any enhancements with these patches, but only with
prerendering. And that does not seem to be perfect. I double checked that the
correct binary has been used.

Sorry for the bad news, I guess we won't see a fully working solution until
texture upload with DMA has in implemented for the non-DRI case as well.

Matthias, thank you for testing the patches!  You've confirmed what I think
several of us suspected -- that there are two completely separate problems with
font rendering.  One that I've fixed (confirmed by Giacomo), and one that you've
discovered.  Unfortunately, the rendering problems that you're seeing I have not
been able to reproduce, so I won't be able to help you fix them until I can
figure out how to do that.

I will go ahead and check in my change to HEAD since it fixes one of the two
separate problems we've found here.

I think your patch has be cleaned up a bit before inclusion.
E.g. it changes the R200 code path, which it shouldn't. You should use another
function, e.g. ATILog2Ceil() in the R100 code path.

Then I'm not exactly clear whether using non-power-of-2 textures with a multiple
of 32 size would help as well - that would use much less texture space. Maybe we
should try that.

(In reply to comment #72)
> I think your patch has be cleaned up a bit before inclusion.
> E.g. it changes the R200 code path, which it shouldn't. You should use another
> function, e.g. ATILog2Ceil() in the R100 code path.

I'm only talking about applying solution #1, not both solutions.  All solution
#1 does is change tex_size in the R100 code path.  The changes to ATILog2 are
only used for the alternate solution #2, which does not currently work on HEAD
due to tiling.

BTW, I've already made a version of my patch that I am planning to apply to HEAD
this afternoon in attachment 2186 [details] [review].  It fixes the problems I've seen here and
Giacomo confirmed works for him as well on HEAD.

> > E.g. it changes the R200 code path, which it shouldn't. You should use another
> > function, e.g. ATILog2Ceil() in the R100 code path.
> 
> I'm only talking about applying solution #1, not both solutions.  All solution
> #1 does is change tex_size in the R100 code path.  The changes to ATILog2 are
> only used for the alternate solution #2, which does not currently work on HEAD
> due to tiling.

I'm not exactly sure whether you don't have to reduce the maximum texture size
to 2047x2047 - because 2048x2048 wouldn't fit into that bitfeld nicely.
Or maybe you can use that (x-1) for the maximum texture case ;)

(In reply to comment #74)
> I'm not exactly sure whether you don't have to reduce the maximum texture size
> to 2047x2047 - because 2048x2048 wouldn't fit into that bitfeld nicely.
> Or maybe you can use that (x-1) for the maximum texture case ;)

Good point.  I'll add that to my patch and reattach it shortly.

Created attachment 2402 [details] [review]
Workaround for R100/RV200 font rendering on HEAD #2

Added check to limit width and height to 2047 when using that code path.

I've been using last workaround (comment #76) with cvs snapshots since two
weeks, without any problem. Any news about is inclusion in HEAD?

Sorry for bothering, but any news on this?

(In reply to comment #78)
> Sorry for bothering, but any news on this?

I've got this on my todo list for testing, which I should be finally able to get
to this week.  It's just a matter of writing a test client (or modifying an
existing one) to explicitly test the cases involved.  I will update again when I
finish full testing.

Hello, I've seen that there are people working on EXA support for the radeon
driver, could this problem (and its fix) interfere with the new code?

Is this now fixed?

(In reply to comment #81)
> Is this now fixed?

no, current CVS still has the bug.

fwiw, i see the same font-rendering problems with Debian's 6.8.2.dfsg.1-9 using
a GeCube Radeon 9250 AGP in MergedFB mode (3200x1200).

lspci -n shows
  0000:01:05.0 0300: 1002:5960 (rev 01)
  0000:01:05.1 0380: 1002:5940 (rev 01)

setting Option "RenderAccel" "off" solves the problem.

rc2 has been released, any hope to see this patch going in (if it is still needed)?

last i checked the radeon texture dimension registers were already (size-1), so
filling them with '2047' should set the texture size on that axis to 2048.

does kem's patch in comment #76 actually fix rendering issues for anyone?  i
haven't been able to reproduce this recently, but i also haven't tried very hard.

(In reply to comment #85)
> does kem's patch in comment #76 actually fix rendering issues for anyone?  i
> haven't been able to reproduce this recently, but i also haven't tried very hard.

yes, that patch fixed all my issues with CVS snapshots up to 6.8.99.16. However
I could not try more recent releases.

I see this same glitch on Xorg 6.9.0 from Debian unstable with a GeForce6600
using the NVidia drivers.  It only seems to happen with GTK2 apps.  Turning off
Render accel. fixes the problem.  I would blame the NVidia drivers except most
people here are using Radeon's with identical result.  If I get time I'll test
my old Radeon 8500.

Hello, 
 
I came here from bug 
 
https://bugs.freedesktop.org/show_bug.cgi?id=5584 (thanks giacomo!) 
 
The latest patch from Kevin seems to have resolved most of the XAA issues for 
me (even if I'm still investigating some pale gray lines in konsole). However 
the EXA+RenderAccel issues remain, i.e.: 
 
1) huge slowdown when scrolling web-pages in Konqueror or Mozilla. There is a 
visible "drawing" effect from top to bottom when scrolling web-pages. The 
effect is visible when grabbing the vertical sidebar of the browser window and 
dragging it up and down fast. Same thing happens when holding down PgUp or 
PdDown button. When moving up and down with scroll-wheel it is not noticeable. 
This slowdown goes away with XAA or EXA + No-RenderAccel. 
 
2) some graphical artifacts on the buttons of kde-apps. Most notably konqueror 
toolbar's buttons and kicker's buttons. There is a visible "hot" pixel in the 
lower right corner of these buttons, which changes color (or sometimes 
disappears) when hovering with the mouse (and thus "highlighting" the button). 
 
xcompmgr/kompmgr does not help in any case, and the artifacts on buttons get 
worse when color depth is lowered to 16. More details in the bugreport linked 
above. 
 
Thoughts? If you need more details or a guinea pig for patches I'm here. The 
problems described are fully reproducible. This is a Radeon IGP 345M with Xorg 
7.0 from Gentoo Packeages (HP laptop). 

The grey lines artifact is still there, even with Kevin's patch. 
 
See here for an example: 
 
http://ing.unitn.it/~rbiscani/screenshots/grey_lines.png 
 
You may need to tweak your monitor's contrast in order to see them, they are 
very weak. It seems like they are generated by the "smearing" of the dot of 
the "i" letter, don't they? 
 
Anyway, I have not noticed other artifacts. The speed problem with EXA 
persists though... 

PING....  
 
... please, can anyone at least comment on the exa+RenderAccel slowdown? 

Hello again, 
 
another piece of the puzzle: 
 
http://lists.freedesktop.org/archives/xorg/2006-February/012897.html 
 
So, my situation has improved a bit. Patch I applied to the radeon driver: 
 
- exa-txoffset from link above 
- kevin's patch from this bugreport 
- BenH's mmap fixes (probably not relevant to this though...) 
 
Current xorg.conf has: 
 
- AccelMethod EXA, 
- RenderAccel enabled, 
- SubPixelOrder "NONE" 
 
Running KDE, and font-antialiasing is turned globally OFF. 
 
With this setup performance is generally acceptable, also when scrolling 
web-pages (weird slowdowns remain though, like @ http://aseigo.blogspot.com). 
Also transparencies are working well. 
 
It may be interesting to note that performance greatly improved (by an order 
of magnitude I'd say) when adding the SubPixelOrder "NONE" option and 
disabling font anti-aliasing. It all seems to point to a font rendering issue. 
Also all drawing artifacts are gone. 
 
Hope this helps a bit. 

(In reply to comment #90)
> ... please, can anyone at least comment on the exa+RenderAccel slowdown? 

This bug is about visual artifacts with RENDER acceleration. There are other
bugs about your issues with EXA, feel free to file new ones for issues that
aren't covered yet.

I'm reading the xorg-team list.

This bug is horribly long and hard to follow now.  Could someone kindly
summarize the current state of the world here?  Otherwise this is getting moved
out to 7.2

(In reply to comment #94)
> This bug is horribly long and hard to follow now.  Could someone kindly
> summarize the current state of the world here?  Otherwise this is getting moved
> out to 7.2

well, I applied the patch attached in comment #76 to my local xorg-server up to
version 1.0.0, then I switched to EXA, that doesn't suffer from this problem, so
I don't know if the patch still works (or if the bug was fixed by other commits).

Giacomo, is XAA still producing the bug using your current setup? 

(In reply to comment #96)
> Giacomo, is XAA still producing the bug using your current setup? 

just tested on xorg-server-1.0.2 and xf86-video-ati-6.5.8.0: the bug is still
here with XAA

(In reply to comment #97)
> just tested on xorg-server-1.0.2 and xf86-video-ati-6.5.8.0: the bug is still
> here with XAA

Unsurprising, attachment #2402 [details] [review] still hasn't been applied.

I'm moving this off the 7.1 tracker since it's a pretty low-impact bug and can
be fixed async in a radeon driver update.  Should definitely get applied though;
would some kindly radeon maintainer handle this please?

> be fixed async in a radeon driver update.  Should definitely get applied though;
> would some kindly radeon maintainer handle this please?

Aparently not.  ;o)

aiui, this has been fixed in the -ati tree.

I have tested Xorg 7.2 from SuSE.
I have tested all versions Xorg currently offers, official + updates, xorg72 repo, xorg73 repo.
I run currently the highest latest and highest version of 7.2 provided.
But I have to report - THE BUG IS STILL THERE.

Notes:
It appears mainly in OOo but some versions showed apparent glitches in Firefox too. I can provide screenshots on request. When RenderAccel is turned off glitches gone away.
Exact versions of relevant packages are:
xorg-x11-driver-video-7.2-149.2
xorg-x11-server-7.2-130.1
xorg-x11-fonts-core-7.2-14
xorg-x11-libXrender-7.2-12
xorg-x11-libX11-7.2-50.1

Uh, this patch has NOT been committed. At least it doesn't seem to be in xf86-video-ati's master branch.

not committed yet

this bug has gotten out of hand, and it is impossible to tell from this what is going on,

If someone can reproduce this problem using 

1. Xorg 7.2
2. ATI driver 6.6.191 or git HEAD
3. can attach an xorg.conf and Xorg.0.log file

Can they open a new bug which doesn't contain so much noise... and I'll attempt to  fix it myself or get someone to do so... this bug is too intractable as it goes back to 6.8 at this point...

closed in git master (http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-ati.git;a=commit;h=197a62704742a4a19736c2637ac92d1dc5ab34ed)