Go Back   nV News Forums > Linux Support Forums > NVIDIA Linux

Newegg Daily Deals

Reply
 
Thread Tools
Old 05-30-06, 01:23 AM   #85
benjiman
Registered User
 
Join Date: Mar 2006
Posts: 3
Default Re: Slow AA text rendering in KDE

Quote:
Originally Posted by d13f00l
There has to be something that is different... A duron beating out an a64 running the same code...it seems impossible.
My cyrix 233 with onboard graphics renders antialiased text faster than my athlon64 with nvidia card + nvidia drivers. With nvidia card the vesa and nv drivers render considerably faster than nvidia's drivers.
benjiman is offline   Reply With Quote
Old 05-30-06, 02:15 AM   #86
Linuxhippy
Registered User
 
Join Date: Feb 2004
Posts: 585
Default Re: Slow AA text rendering in KDE

Quote:
Originally Posted by d13f00l
Regression? Several versions ago, subpixel AA was actually accelerated. It was disabled since then, because it rendered improperly. You're talking about that QT program that draws fonts that was posted before, right?
I don't know wether its a driver regression or a GPU regression, so that at least the 6600 series isn't able to perform subpixel-AA as fast as a cheap FX5200 with the same drivers.

Quote:
Post your .fonts.conf file in your home directory on both PCs. Also, what font are you using, on both PCs? Can you try arial? Arial has byte code info in it, so it makes for a good test.
Ok, I'll have a look, the next days I'll get access to that computer again.

Quote:
There has to be something that is different... A duron beating out an a64 running the same code...it seems impossible.
Well there are some different things, another graphic card and another chipset. However I hardly believe its tha chipset since many people reported problems only using the 6x00 series.

lg Clemens
Linuxhippy is offline   Reply With Quote
Old 06-06-06, 06:49 AM   #87
Schpauli
Registered User
 
Join Date: Jun 2006
Posts: 1
Default Re: Slow AA text rendering in KDE

It seems to me that you all compared two different machines one with the 6600 card and one with a different graphics board. Last week I bought a new card with nVidia 6600 GPU because my old ati card is broken and now I have problems with subpixel hinting in kde-3.5 applications, which I did not have with my old card. Although these are not as bad as in the vidio benjiman made.

All I changed was uninstalling ati-drivers and installing the nvidia-1.0-8756 drivers. That's why I think it can't be KDE.
Schpauli is offline   Reply With Quote
Old 07-20-06, 03:07 PM   #88
Linuxhippy
Registered User
 
Join Date: Feb 2004
Posts: 585
Default Re: Slow AA text rendering in KDE

I just wanted to warm-up this topic ... since I guess I've found an explanation why GTK performs much better than QT based applications.

GTK uses a lot of very short-living pixmaps which are never moved to vram (so, almost all rendering in GTK applications is done in software and you GPU stays unused).
And because the most expensive part of software rendering to hw-accalerated surfaces is vram-readback and upload its a lot faster since the desination surface is already in RAM.
After drawing a singly large ram->vram transport happens instead of many small ones, which again should be faster.

So GTK has faster subipxel-rendering more or less through an accident, but looses almost all possible hw-accalerated drawing. I hope both problems will be addressed in future.

lg Clemens
Linuxhippy is offline   Reply With Quote
Old 07-20-06, 08:04 PM   #89
zbiggy
Registered User
 
Join Date: Sep 2002
Posts: 623
Default Re: Slow AA text rendering in KDE

Quote:
Originally Posted by Linuxhippy
However I hardly believe its tha chipset since many people reported problems only using the 6x00 series.

lg Clemens
I do not know if this will help you with investigation but I have geforce 6150 which belongs to 6x00 series and works OK. So not all geforces 6 are bad. Maybe this is because my geforce as integrated graphics has no onboard VRAM and uses system memory as pseudo VRAM? I set 64MB for framebuffer in BIOS.

There is no speed difference between firefox, kwrite, kedit, kate and other apps. Everything runs with same speed. KDE 3.5.3, qt 3.3.5, xorg 6.9.0, RenderAccel="1", Athlon64 3000+ Venice, 4x256MB RAM, Asus A8N-VM CSM.

I have the same drawing speed on second machine: same software config, AthlonXP 2500+ Barton, 2x256MB Twinbank, Abit NF7-S v2.0, FX5200 AGP with 64MB VRAM.

Geforce 6150 and geforce FX5200 looks the same in Linux. It is sad that new and old generation are the same. The top feature of geforce 6 family - purevideo does not exist in Linux. Very bad. DVDs with TV shows recordings looks ugly because deinterlacing is none. Where is this advanced deinterlacing of geforce6?
zbiggy is offline   Reply With Quote
Old 07-21-06, 05:38 AM   #90
Linuxhippy
Registered User
 
Join Date: Feb 2004
Posts: 585
Default Re: Slow AA text rendering in KDE

The problem is known only for GF6xxx series with dedicated VRAM, a gf61xx does not have seperate vram -> nothing has to go over system-bus.

My FX5200 card is about 4-8x faster when doing subpixel glyph rendering than my GF6600.

lg Clemens

PS: <ironic>thanks for mentioning all the other stuff again</ironic>
Linuxhippy is offline   Reply With Quote
Old 07-21-06, 05:22 PM   #91
zbiggy
Registered User
 
Join Date: Sep 2002
Posts: 623
Default Re: Slow AA text rendering in KDE

Quote:
Originally Posted by zbiggy
Geforce 6150 and geforce FX5200 looks the same in Linux. It is sad that new and old generation are the same. The top feature of geforce 6 family - purevideo does not exist in Linux. Very bad. DVDs with TV shows recordings looks ugly because deinterlacing is none. Where is this advanced deinterlacing of geforce6?
Yes. Sorry for that. But every time I write something about geforce 6 Linux driver this deinterlacing comes to my mind and make me very angry.
zbiggy is offline   Reply With Quote
Old 07-21-06, 11:34 PM   #92
d13f00l
Registered User
 
Join Date: Apr 2005
Posts: 197
Default Re: Slow AA text rendering in KDE

Quote:
Originally Posted by Linuxhippy
I just wanted to warm-up this topic ... since I guess I've found an explanation why GTK performs much better than QT based applications.

GTK uses a lot of very short-living pixmaps which are never moved to vram (so, almost all rendering in GTK applications is done in software and you GPU stays unused).
And because the most expensive part of software rendering to hw-accalerated surfaces is vram-readback and upload its a lot faster since the desination surface is already in RAM.
After drawing a singly large ram->vram transport happens instead of many small ones, which again should be faster.

So GTK has faster subipxel-rendering more or less through an accident, but looses almost all possible hw-accalerated drawing. I hope both problems will be addressed in future.

lg Clemens
Subpixel AA currently is done in software, anyway. There is no acceleration. If KDE applications are doing software graphical operations in video ram, that would explain the issue. It's a waste of bandwidth to be moving things from video ram to system ram when there's no acceleration being done in VRAM anyway. I wouldn't call it an accident, it's more like a blessing since subpixel font aa is pretty complicated to accelerate anyway, maybe GTK developers realize this and implemented it as such.

There's something wrong with Nvdia's render acceleration, probably, as well. That's going to be worked on more, I'm sure.

I've developed a strong distaste for QT apps over the past 6 months, UI inconsistencies and issues with font AA. I switched to GTK and XFCE and I haven't looked back.
d13f00l is offline   Reply With Quote

Old 07-22-06, 06:42 AM   #93
SaTaN0rX
Registered User
 
Join Date: Apr 2005
Posts: 86
Default Re: Slow AA text rendering in KDE

another thought:

if that sucks on 6600's, but don't suck on a 6150, maybe the PCIe
host interface is penalizing you?

unfortunately my 6800 agp has died
so i can't run your test.

but to verify this theory, one should run the tests on any of this cards:

NV40 based 6800 AGPs
NV44A based 6200 AGPs.

note that 6600 AGP still has the PCIe interface and an PCIe <-> AGP bridge.

based upon all i know abut the PCIe interface, it would make sense that it
does penalize multiple small transfers.
SaTaN0rX is offline   Reply With Quote
Old 07-22-06, 07:04 AM   #94
Linuxhippy
Registered User
 
Join Date: Feb 2004
Posts: 585
Default Re: Slow AA text rendering in KDE

Quote:
Originally Posted by d13f00l
It's a waste of bandwidth to be moving things from video ram to system ram when there's no acceleration being done in VRAM anyway. I wouldn't call it an accident, it's more like a blessing since subpixel font aa is pretty complicated to accelerate anyway, maybe GTK developers realize this and implemented it as such.
1.) GTK creates short-living pixmaps wich are never moved to VRAM - this SLOWS DOWN GTK BY 25% overall. GTK devs have reasons why they do so (although I think it has some major drawbacks), but it seems nvidia drivers cope really bad with this case.
I don't see a reason to do all rendering by the CPU, just because one frequently used operation is not accalerated (but could be) in hardware - and thats why GPUs and vram exist, to do rendering _there_.

2.) No one says subpixel-AA has to be accalerated, but it should be "fast enough".
With fast enough I mean that I can work without noticing ugly slowness with "normal" applications, who cares about benchmarks.

3.) Well then I whish you a lot of fun with XFCE. Keep in mind you're GPU practically does nothing more than displaying the stuff calculated by you CPU *lol
Its a bit like changing your car just because with the tires you put onto it you can't driver more than 50km/h.

best whishes, lg Clemens
Linuxhippy is offline   Reply With Quote
Old 07-22-06, 07:28 AM   #95
SaTaN0rX
Registered User
 
Join Date: Apr 2005
Posts: 86
Default Re: Slow AA text rendering in KDE

Quote:
Originally Posted by Linuxhippy
1.) GTK creates short-living pixmaps wich are never moved to VRAM - this SLOWS DOWN GTK BY 25% overall. GTK devs have reasons why they do so (although I think it has some major drawbacks), but it seems nvidia drivers cope really bad with this case.
I don't see a reason to do all rendering by the CPU, just because one frequently used operation is not accalerated (but could be) in hardware - and thats why GPUs and vram exist, to do rendering _there_.
IMHO GPUs and VRAM exist to do heavy things there. By heavy things i mean
3D, and posible some video decoding aceleration. but thats my oppinion.

Quote:
2.) No one says subpixel-AA has to be accalerated, but it should be "fast enough".
With fast enough I mean that I can work without noticing ugly slowness with "normal" applications, who cares about benchmarks.
if it is fast enough with some apps, and some others have problems, maybe it's the app.

Quote:
3.) Well then I whish you a lot of fun with XFCE. Keep in mind you're GPU practically does nothing more than displaying the stuff calculated by you CPU *lol
Its a bit like changing your car just because with the tires you put onto it you can't driver more than 50km/h.
ok. but thats my understanding of 2D. the CPU does the rendering stuff, the GFX card only displays it on the monitor.

ok, my gpu is sitting lazy around. but, with OpenOffice, i can even use
cool'n'quiet to downclock my cpu and i notice no speed impact, cause things like OOo can't really drive a modern cpu to anything near 100%.
so i see really no use in trying to offload more work to the GPU in such situations, considering the major drawbacks: bus usage, difficult software, ...

you might say that if you compile something in the background, while using
OOo will slower as necessary, cause the gpu can offload OOo gfx stuff, and
you got more cpu ressources for compiling, but to be honest, such situations
do not occur too often.
SaTaN0rX is offline   Reply With Quote
Old 07-22-06, 08:58 AM   #96
Linuxhippy
Registered User
 
Join Date: Feb 2004
Posts: 585
Default Re: Slow AA text rendering in KDE

Quote:
if it is fast enough with some apps, and some others have problems, maybe it's the app.
No, nvidia devs confirmed the problem. I am too lazy to start this discussion every time again and again when I add another piece of information.

Quote:
ok. but thats my understanding of 2D. the CPU does the rendering stuff, the GFX card only displays it on the monitor.
First of all OOo does not do double-buffering nore does it support subpixel-AA, therefor its fully accalerated anyway.
There are chips that do basically just what you described (well, basically they also support the full 2d stack today, since it doesn't make much difference wether you support them or not keeping die size in mind), but there are priced arround 10$, if I pay 100$ I would like to get something which is worth the money.
Furthermore I guess you've never had X running on top of a VESA-FB display which is horrible slow and CPU hogging, otherwise you would not throw arround with such statements.

lg Clemens
Linuxhippy is offline   Reply With Quote
Reply


Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


Similar Threads
Thread Thread Starter Forum Replies Last Post
Fedora KDE 16 Geforce GTX260 and slow gtk applications Rendering NVIDIA Linux 10 07-11-13 07:02 AM
[GeForce 8800 GTS] 2D rendering regression (extreme slowdown) introduced with 295.49 Seb L. NVIDIA Linux 0 06-22-12 06:48 AM
Very slow X startup Jeremy NVIDIA Linux 96 05-23-03 10:11 AM
NVidia Display Drivers screw up KDE Webgraph NVIDIA Linux 11 10-08-02 08:57 PM
poor kde X windows performance after restart HeadStrong NVIDIA Linux 5 08-19-02 07:17 PM

All times are GMT -5. The time now is 09:19 PM.


Powered by vBulletin® Version 3.7.1
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Copyright 1998 - 2014, nV News.