Hello,
the agpgart backend is now always compiled in and selected with 2.6.11-rc3
x86_64. I can delete or disable it in the config, it is always back written.
Is this the default future behaviour? The eg Nforce3 AGP is on a normal
desktop so slow on 2D and also in 3D mode a lot slower and all nvidia
kernel driver users can not more use the really faster nv_agp.
Greetings,
Marcus
On Fri, Feb 11, 2005 at 07:07:22AM +0100, Marcus Hartig wrote:
> the agpgart backend is now always compiled in and selected with 2.6.11-rc3
> x86_64. I can delete or disable it in the config, it is always back written.
probably you have selected IOMMU, which is dependant on it.
> Is this the default future behaviour?
This is how it's always been.
> The eg Nforce3 AGP is on a normal desktop so slow on 2D and also in 3D mode
> a lot slower and all nvidia kernel driver users can not more use the really
> faster nv_agp.
This surprises me, especially considering the in-kernel nvidia-agp driver
was actually written by NVidia. Are there any agp error messages in
your dmesg / X log ?
How big a speed difference do you notice with the two gart drivers?
Dave
Dave Jones wrote:
> probably you have selected IOMMU, which is dependant on it.
Yes, thanks. Sorry my fault. I had it not deactivated, arggg.
> This surprises me, especially considering the in-kernel nvidia-agp driver
> was actually written by NVidia. Are there any agp error messages in
> your dmesg / X log ?
No warnings/errors in both logs. All clean. But switching/maximizing
between tasks like firefox, thunderbird or a gnome-terminal is so slow,
that you can see it how firefox/GTK+ theme is writing the GUI and the
fonts slowly back. Minimizing is no more fun, like a fast slide-show. And
that on a fast amd64 3200 with 1 GB RAM and a FX 5900XT. :(
With the nVidia own nv_agp it appears directly in all apps, very fast
under GNOME 2.8.1. Why, I do not know. Also game (opengl) performance is
faster with the nv_agp, that I haven't used the kernel agp for months, now.
Greetings,
Marcus
> > This surprises me, especially considering the in-kernel nvidia-agp driver
> > was actually written by NVidia. Are there any agp error messages in
> > your dmesg / X log ?
> With the nVidia own nv_agp it appears directly in all apps, very fast
> under GNOME 2.8.1. Why, I do not know. Also game (opengl) performance is
> faster with the nv_agp, that I haven't used the kernel agp for months, now.
This is interesting. I always used agpgart without a second thought (2.4.29,
GeForce4 MX with Via KT133 chipset).
I just read through the nVidia readme file, and there is a comprehensive
section on what module to use for what chipset (and card). It recommends
using the nVagp for my setup, so I just rebuilt excluding agpgart so I can
use the nVdia module.
I never had slowness as such in KDE or X apps, but playing quake2 openGL I
used to get a 'wave' type effect rippling down the screen occasionally. A
quick test using the nVagp module to have fixed that...
I will test for a few weeks.
Nick
--
"When you're chewing on life's gristle,
Don't grumble, Give a whistle..."
On Fri, Feb 11, 2005 at 05:21:39PM +0100, Marcus Hartig wrote:
> No warnings/errors in both logs. All clean. But switching/maximizing
> between tasks like firefox, thunderbird or a gnome-terminal is so slow,
> that you can see it how firefox/GTK+ theme is writing the GUI and the
> fonts slowly back. Minimizing is no more fun, like a fast slide-show. And
> that on a fast amd64 3200 with 1 GB RAM and a FX 5900XT. :(
None of this involves 3D operation, or AGPGART.
> With the nVidia own nv_agp it appears directly in all apps, very fast
> under GNOME 2.8.1. Why, I do not know. Also game (opengl) performance is
> faster with the nv_agp, that I haven't used the kernel agp for months, now.
*shrug*, if the nvidia module is properly configured, it should make
no difference at all. AGPGART operation isn't a performance critical
thing, as the hardware does 99% of the work.
Dave
On Fri, Feb 11, 2005 at 06:04:06PM +0000, Nick Warne wrote:
> > > This surprises me, especially considering the in-kernel nvidia-agp driver
> > > was actually written by NVidia. Are there any agp error messages in
> > > your dmesg / X log ?
>
> > With the nVidia own nv_agp it appears directly in all apps, very fast
> > under GNOME 2.8.1. Why, I do not know. Also game (opengl) performance is
> > faster with the nv_agp, that I haven't used the kernel agp for months, now.
>
> This is interesting. I always used agpgart without a second thought (2.4.29,
> GeForce4 MX with Via KT133 chipset).
>
> I just read through the nVidia readme file, and there is a comprehensive
> section on what module to use for what chipset (and card). It recommends
> using the nVagp for my setup, so I just rebuilt excluding agpgart so I can
> use the nVdia module.
>
> I never had slowness as such in KDE or X apps, but playing quake2 openGL I
> used to get a 'wave' type effect rippling down the screen occasionally. A
> quick test using the nVagp module to have fixed that...
Terrence, any ideas ?
The only thing that jumps to mind that the nvidia gart driver is doing
that the opensource one isn't is fiddling with PAT bits in the GART
pages, but if anything, that should be just a performance thing.
(It'd be really nice to get your PAT support in 2.6 sometime too btw).
Dave
Dave Jones wrote:
> *shrug*, if the nvidia module is properly configured, it should make
> no difference at all. AGPGART operation isn't a performance critical
> thing, as the hardware does 99% of the work.
Yes, that was also my opinion, but after using AGPGART, hmm.
And it was on my last 32 bit FC2 systems with other hardware the same slow
operations on the desktop. And I'm not alone, there are some nvnews.net
linux forum users which report the same slow performance with AGPGART.
Maybe the linux kernel AGPGART do not run well with the nVidia 2D
acceleration renderer or the kernel driver and is a nvidia problem.
http://www.marcush.de/Xorg.0.log
Greetings,
Marcus
On Fri, Feb 11, 2005 at 01:48:21PM -0500, [email protected] wrote:
> On Fri, Feb 11, 2005 at 06:04:06PM +0000, Nick Warne wrote:
>
> > > > This surprises me, especially considering the in-kernel nvidia-agp driver
> > > > was actually written by NVidia. Are there any agp error messages in
> > > > your dmesg / X log ?
> >
> > > With the nVidia own nv_agp it appears directly in all apps, very fast
> > > under GNOME 2.8.1. Why, I do not know. Also game (opengl) performance is
> > > faster with the nv_agp, that I haven't used the kernel agp for months, now.
> >
> > This is interesting. I always used agpgart without a second thought (2.4.29,
> > GeForce4 MX with Via KT133 chipset).
> >
> > I just read through the nVidia readme file, and there is a comprehensive
> > section on what module to use for what chipset (and card). It recommends
> > using the nVagp for my setup, so I just rebuilt excluding agpgart so I can
> > use the nVdia module.
> >
> > I never had slowness as such in KDE or X apps, but playing quake2 openGL I
> > used to get a 'wave' type effect rippling down the screen occasionally. A
> > quick test using the nVagp module to have fixed that...
>
> Terrence, any ideas ?
I would agree with your assessment Dave, there's very little
difference betweeen the agp drivers. it's possible nvagp tweaks some
register values that agpgart doesn't, I'd have to look closer at both
to know. that might explain *modest* performance differences, but
certainly wouldn't explain the dramatic performance differences the
original poster described.
I wouldn't expect even falling back to pci dma would have this big of an
impact on 2d performance, but perhaps there's enough bus activity for this
to happen. Marcus, can you verify that you're actually using agpgart
in that situation? do you possibly have our XF86Config option set to
nvagp only? (with IOMMU compiled in or agpgart loaded, our driver
won't allow nvagp) you can verify whether agp is enabled with this
command when our driver is loaded and X is started up:
% cat /proc/drivers/nvidia/agp/status
Status: Disabled
(hmm, turns out my own dev machine doesn't have agp enabled and 2d
performance isn't very noticeable)
> > I just read through the nVidia readme file, and there is a comprehensive
> > section on what module to use for what chipset (and card). It recommends
> > using the nVagp for my setup,
is that the "CONFIGURING AGP" appendix? I didn't think that we
recommended which agp driver to use. the intention was just to
document which chipsets are supported by nvagp and point out that
agpgart may/probably supports more chipsets. that section also
documents some hardware 'issues' that we work around. we work around
these issues regardless of which agp driver is being used.
for this via kt133 issue, I looked through the agpgart and nvagp
initializations and didn't see anything much different. both
initialize and flush gart mappings the same way. both seem to allocate
memory the same way (nvagp uses __get_free_pages, which eventually
calls alloc_pages) with the GFP_KERNEL flag. I'm not sure why there
would be much difference between the two.
> (It'd be really nice to get your PAT support in 2.6 sometime too btw).
I've been meaning to finish that up. the actual PAT support is pretty
simple; it's the protecting against cache aliasing that's a bit tricky
and involved. for our push buffers, we don't worry too much about the
cache aliasing, since change_page_attr() marks the kernel mapping
uncached, and there shouldn't be any other mappings to the memory.
mapping i/o regions like the framebuffer is a bit riskier, since it's
more likely someone else has a conflicting mapping to it, but the
damage of data corruption is much less fatal.
Thanks,
Terence
On Friday 11 February 2005 22:19, Terence Ripperda wrote:
> > > I just read through the nVidia readme file, and there is a
> > > comprehensive section on what module to use for what chipset (and
> > > card). It recommends using the nVagp for my setup,
>
> is that the "CONFIGURING AGP" appendix? I didn't think that we
> recommended which agp driver to use. the intention was just to
> document which chipsets are supported by nvagp and point out that
> agpgart may/probably supports more chipsets. that section also
> documents some hardware 'issues' that we work around. we work around
> these issues regardless of which agp driver is being used.
Thats the one. I read this in APPENDIX F:
"The following AGP chipsets are supported by NVIDIA's AGP; for all other
chipsets it is recommended that you use the AGPGART module."
as saying 'if you have one of these chipsets use nVagp' else use agpgart.
> for this via kt133 issue, I looked through the agpgart and nvagp
> initializations and didn't see anything much different. both
> initialize and flush gart mappings the same way. both seem to allocate
> memory the same way (nvagp uses __get_free_pages, which eventually
> calls alloc_pages) with the GFP_KERNEL flag. I'm not sure why there
> would be much difference between the two.
I have had no issue at all running agpgart on Slackware 10 with KDE 3.3.x. It
was just when I read this thread I didn't realise there was another option of
a different NV module. I just tried it after reading deeper in the
readme.txt ref. the Quake2 OpenGL 'rippling wave' I get every 5 minutes or
so. It fixed it, BTW. I now have a constant clear display 100% in Quake2 :)
I haven't noticed any difference at all in 2d desktop stuff (except maybe it
is slightly brighter).
Nick
--
"When you're chewing on life's gristle,
Don't grumble, Give a whistle..."
Terence Ripperda wrote:
> I wouldn't expect even falling back to pci dma would have this big of an
> impact on 2d performance, but perhaps there's enough bus activity for
> this to happen. Marcus, can you verify that you're actually using
> agpgart in that situation? do you possibly have our XF86Config option
> set to nvagp only? (with IOMMU compiled in or agpgart loaded, our driver
> won't allow nvagp) you can verify whether agp is enabled with this
> command when our driver is loaded and X is started up:
No, IOMMU is now off, too. And I have always used nv_agp with:
Option "NvAgp" "1"
If the nvidia driver detects the kernel agpgart, it doesn't load nv_agp
with a big message in the kernel log.
I've just short tested it again:
Doom3 with medium standard settings in 800x600@24bit:
agpgart: 58,1 frames
nv_agp: 63,1 frames
Its a lot in Doom3.
(Simple) 2D test 1280x1024@24bit with x11perf --> http://www.marcush.de/bench/
Same gcc, xorg 6.8.2, 2.6.11-rc3-bk8 kernel, patched (minion.de) 6629
nvidia drivers to run with newer 2.6.11-rcX kernel,... here was only
nv_agp and agpgart the difference. In the past without an patched driver
the same difference.
And again using agpgart with GNOME under X and moving this thunderbird
mail window or other bigger ones like mozille or firefox over an
gnome-terminal pulls/draws a ca. 5cm shadow like field slowly after the
main window. It seems so not fast enough writing to the screen, when
moving. With nv_agp its really faster and you do not see this.
Bad english... I know. ;)
Greetings,
Marcus
> agpgart: 58,1 frames
> nv_agp: 63,1 frames
>
> Its a lot in Doom3.
hmm I wonder.. .could you collect lspci -vxxx settings for the AGP
device (lspci -vxxx gives you lots of devices, but only one is relevant)
in both cases, maybe the difference between the two shows something
useful...
Arjan van de Ven wrote:
> hmm I wonder.. .could you collect lspci -vxxx settings for the AGP
> device (lspci -vxxx gives you lots of devices, but only one is relevant)
> in both cases, maybe the difference between the two shows something
> useful...
Hmmm...only the latency at the VGA card.
With AGPGART:
01:00.0 VGA compatible controller: nVidia Corporation NV35 [GeForce FX
5900] (rev a1) (prog-if 00 [VGA])
Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 5
Memory at e0000000 (32-bit, non-prefetchable) [size=16M]
Memory at d8000000 (32-bit, prefetchable) [size=128M]
Capabilities: [60] Power Management version 2
Capabilities: [44] AGP version 3.0
00: de 10 31 03 07 00 b0 02 a1 00 00 03 00 20 00 00
10: 00 00 00 e0 08 00 00 d8 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 60 00 00 00 00 00 00 00 05 01 05 01
40: 00 00 00 00 02 00 30 00 1b 0e 00 1f 00 00 00 00
50: 01 00 00 00 01 00 00 00 ce d6 23 00 0f 00 00 00
60: 01 44 02 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
With NV_AGP:
01:00.0 VGA compatible controller: nVidia Corporation NV35 [GeForce FX
5900] (rev a1) (prog-if 00 [VGA])
Flags: bus master, 66Mhz, medium devsel, latency 248, IRQ 5
Memory at e0000000 (32-bit, non-prefetchable) [size=16M]
Memory at d8000000 (32-bit, prefetchable) [size=128M]
Capabilities: [60] Power Management version 2
Capabilities: [44] AGP version 3.0
00: de 10 31 03 07 00 b0 02 a1 00 00 03 00 f8 00 00
10: 00 00 00 e0 08 00 00 d8 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 60 00 00 00 00 00 00 00 05 01 05 01
40: 00 00 00 00 02 00 30 00 1b 0e 00 1f 02 43 00 1f
50: 01 00 00 00 01 00 00 00 ce d6 23 00 0f 00 00 00
60: 01 44 02 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Both complete output: http://www.marcush.de/bench/
Greetings,
Marcus
On Sat, Feb 12, 2005 at 08:36:13PM +0100, Marcus Hartig wrote:
> Arjan van de Ven wrote:
>
> >hmm I wonder.. .could you collect lspci -vxxx settings for the AGP
> >device (lspci -vxxx gives you lots of devices, but only one is relevant)
> >in both cases, maybe the difference between the two shows something
> >useful...
>
> Hmmm...only the latency at the VGA card.
Was there any differnces in the devices at 00:00.0 and 00:01.0 ?
(host & pci bridges)
Dave
Dave Jones wrote:
> Was there any differnces in the devices at 00:00.0 and 00:01.0 ?
> (host & pci bridges)
Only the Host bridge line c0:
With AGPGART:
00:00.0 Host bridge: nVidia Corporation: Unknown device 00e1 (rev a1)
Subsystem: Micro-Star International Co., Ltd.: Unknown device 0300
Flags: bus master, 66Mhz, fast devsel, latency 0
Memory at d0000000 (32-bit, prefetchable) [size=128M]
Capabilities: [44] HyperTransport: Slave or Primary Interface
Capabilities: [c0] AGP version 3.0
00: de 10 e1 00 06 00 b0 00 a1 00 00 06 00 00 00 00
10: 08 00 00 d0 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 62 14 00 03
30: 00 00 00 00 44 00 00 00 00 00 00 00 ff 00 00 00
40: 62 14 00 03 08 c0 c0 01 22 00 11 11 d0 00 00 00
50: 23 05 3f 00 03 00 00 00 00 00 00 00 00 00 00 00
60: 32 31 03 00 66 45 04 00 66 06 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 30 30 00 00 11 11 88 00
80: 13 88 88 00 c8 00 00 00 70 00 00 00 3f 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 07 00 00 00 66 00 66 00 00 00 00 00 00 00 00 00
c0: 02 00 30 00 1b 42 00 1f 01 00 00 00 ff ff ff ff
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
With NV_AGP:
00:00.0 Host bridge: nVidia Corporation: Unknown device 00e1 (rev a1)
Subsystem: Micro-Star International Co., Ltd.: Unknown device 0300
Flags: bus master, 66Mhz, fast devsel, latency 0
Memory at d0000000 (32-bit, prefetchable) [size=128M]
Capabilities: [44] HyperTransport: Slave or Primary Interface
Capabilities: [c0] AGP version 3.0
00: de 10 e1 00 06 00 b0 00 a1 00 00 06 00 00 00 00
10: 08 00 00 d0 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 62 14 00 03
30: 00 00 00 00 44 00 00 00 00 00 00 00 ff 00 00 00
40: 62 14 00 03 08 c0 c0 01 22 00 11 11 d0 00 00 00
50: 23 05 3f 00 03 00 00 00 00 00 00 00 00 00 00 00
60: 32 31 03 00 66 45 04 00 66 06 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 30 30 00 00 11 11 88 00
80: 13 88 88 00 c8 00 00 00 70 00 00 00 3f 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 07 00 00 00 66 00 66 00 00 00 00 00 00 00 00 00
c0: 02 00 30 00 1b 42 00 1f 02 03 00 00 ff ff ff ff
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Greetings,
Marcus