|
Description
Giacomo Perale
2004-09-20 01:37:45 UTC
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... |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
