FreeBSD x64 NVIDIA DRIVER - now possible

[srinivas]

Now with TLS (thread-local storage) and GART support well supported for FreeBSD-amd64/6.0-STABLE, with Linux x86-64 and FreeBSD x86 supported, it seems that there is no reason that there should not be a FreeBSD x86-64 driver, as the community is growing, and those in this forum only represent a small minority of the total FreeBSD AMD64 users with NVIDIA (we all know open-sourcers love NVIDIA_; exp. that now the 7800 is the BEST GRAPHICS CARD, AMD64 - the BEST PROCESSOR; FreeBSD - the BEST OS).

Because of this, I am forced to use the x86 version of FreeBSD (I need 3d graphics b/c I use them a lot and hope my 64 bit addressing will save me sometime). It is not that the FreeBSD Kernel (or any other kernel) support 32 bit drivers, so it seems that we need a 64 bit driver for the best processing and best graphics possible (with X.Org).

[Forge]

I heard Nvidia was waiting on some memory management controls to be added. Can anyone @nvidia.com comment on this? If there is something yet to be done on the BSD side, I'd like to go bug the BSD devs instead, but if there's nothing left pending on their side, Nvidia should really get on this.

[AnXa]

BSD isn't that good for gaming, but better server than most of the servers in market... ^^;

..thought I prefer GNU more than anything.

[arokh]

Why are you running 64-bit on workstations anyways? I don't get it.

[Marcin Komar]

FreeBSD is still missing the PAT feature
On freebsd lists John Baldwin (jhb@) told me: http://lists.freebsd.org/pipermail/freebsd-current/2005-November/057808.html

"It's not finished, no. The WIP is being done in the p4_pat branch (though it has some crud in it now that probably isn't needed). For more info about PAT and memory caching modes on x86 including MTRR's, etc. you can go download the vol 2 IA-32 arch PDF from developer.intel.com. It's not a conspiracy, there are no black helicopters."

Documentation can be downloaded from here:
http://www.intel.com/design/pentium4/manuals/index_new.htm
System programming guide (253668) chapter 10.12 PAGE ATTRIBUTE TABLE (PAT)

John's code branch is here:
http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=/depot/user/jhb/pat&HIDEDEL=YES

John Baldwin released a patch against CURRENT (still not ready to commit) here:
http://people.freebsd.org/~jhb/patches/pat.patch


So.. the only way to get nvidia amd64 driver faster is to dig into the code and send patches to jhb at freebsd dot org

m.

[jjthomas]

Why are you running 64-bit on workstations anyways? I don't get it.

I do video and audio editing. Why should I penalize myself with being forced to run in a mode (i386) thats supports half the capacity of what my hardware (amd64) is capable of doing?

...besides, why would one want to do something based on technology that is so old it is already in the history books?

-J

[arokh]

I do video and audio editing. Why should I penalize myself with being forced to run in a mode (i386) thats supports half the capacity of what my hardware (amd64) is capable of doing?

...besides, why would one want to do something based on technology that is so old it is already in the history books?

-J

Half capacity? When are people going to learn, 64 bits does not mean double the performance. Most likely you'll have worse performance.

[saphire]

Are there any short term solutions for AMD64/nv support. The problem is that I got a 64Bit system (because it was at the right price) and I have a 6800GT. I'm running FreeBSD because it offers 64bit support, which a lot of other OS's aren't in full yet. Also is there any ETA when the driver might be complete?

[arokh]

Why does everybody think they NEED to run 64 bit because their CPU supports it? I'll let you in on a secret, you don't! It's not gonna double your performance, and if you don't know what 64 bit is you don't need it.

[gilboa]

Why does everybody think they NEED to run 64 bit because their CPU supports it? I'll let you in on a secret, you don't! It's not gonna double your performance, and if you don't know what 64 bit is you don't need it.

Let me think about it for a second (and I'm talking about FreeBSD and Linux.)
A. Double the number of GP registers. (No more need to keep pushing registers in and out of main memory)
B. Direct support for >1GB of memory. (2G/2G is slowing down memory hungry user-land applications; high memory kills the performance).

Cheers,

[uOpt]

B. Direct support for >1GB of memory. (2G/2G is slowing down memory hungry user-land applications; high memory kills the performance).


Nope.

[gilboa]

Flame-bait?

[uOpt]

Rubbish busting.

[Freedevil]

Why does everybody think they NEED to run 64 bit because their CPU supports it? I'll let you in on a secret, you don't! It's not gonna double your performance, and if you don't know what 64 bit is you don't need it.

Point taken, but you fail to see if you did purchase a 64bit why be forced to run x86 instead of amd64, their reasoning might not make sense neither does yours to some extent. You sit here preach oh dont complain, why do you need to run 64bit.. well heres what i have to say to you to each their own. But dont put them down cause they choose to run amd64 and want the drivers.

[codedragon76]

Rubbish busting.

If you are rubbish busting, you may want to be more accurate. There is almost no chance of 64bit code running slower than 32bit code. And while the 64bit chips will run most software at equivelent speeds in 32bit mode, some applications, like MySQL, will see a marked improvement in speed. Running 64 bit will also allow the computer to take advantage of many of the new processor commands that are not present in the 32bit spec.

[uOpt]

If you are rubbish busting, you may want to be more accurate. There is almost no chance of 64bit code running slower than 32bit code. And while the 64bit chips will run most software at equivelent speeds in 32bit mode, some applications, like MySQL, will see a marked improvement in speed. Running 64 bit will also allow the computer to take advantage of many of the new processor commands that are not present in the 32bit spec.

Uh?

You seem to have lost context entirely.

Look again what I was commenting on. That nonsense about the supposed slowdown above 1 GB and how the "2GB/2GB" split (nice one) is "hurting performance". Which is all rubbish, and pretty good one.

And if you have never seen a single piece of software run slower in 64 bit mode than 32 bit mode, just go as far as bzip2. I never said it is common but it does exist.

As for what you call "the new processor commands", do you have any idea what you are talking about? Like "sit" and "play dead"?

Is this a zoo?

You people don't deserve a new driver.

[codedragon76]

Uh?

You seem to have lost context entirely.

Look again what I was commenting on. That nonsense about the supposed slowdown above 1 GB and how the "2GB/2GB" split (nice one) is "hurting performance". Which is all rubbish, and pretty good one.

And if you have never seen a single piece of software run slower in 64 bit mode than 32 bit mode, just go as far as bzip2. I never said it is common but it does exist.

As for what you call "the new processor commands", do you have any idea what you are talking about? Like "sit" and "play dead"?

Is this a zoo?

You people don't deserve a new driver.


Strange that they would design a whole brand new chip, based on a new architecture mind you, and never bother to optimise the chip by adding new optimised processor commands.... Oh wait.. they did add new optimizations. Therefore don't try to come off all educated, you are embarresing yourself.

[uOpt]

Strange that they would design a whole brand new chip, based on a new architecture mind you, and never bother to optimise the chip by adding new optimised processor commands.... Oh wait.. they did add new optimizations. Therefore don't try to come off all educated, you are embarresing yourself.

Okay, they added new optimizations. And algorithms. And logarithms.

Did we actually disagree on anything? Last time I looked you were just sniping on me just for pointing out that memory above 1 GB is not slower (it isn't) and that the 2/2GB boundary (which neither FreeBSD nor Linux have) make things "slower" (which they don't).

I don't see what anything you said has to do with any of that, except that you made that claim that there is no single program running slower in 64 bit mode than 32 bit mode. If you know what a pointer size is it should be pretty obvious to you that I can easily come up with example programs that run slower. How about one of the fancy string representations that have charaters in linked lists?

[gilboa]

Uh?

You seem to have lost context entirely.

Look again what I was commenting on. That nonsense about the supposed slowdown above 1 GB and how the "2GB/2GB" split (nice one) is "hurting performance". Which is all rubbish, and pretty good one.

And if you have never seen a single piece of software run slower in 64 bit mode than 32 bit mode, just go as far as bzip2. I never said it is common but it does exist.

As for what you call "the new processor commands", do you have any idea what you are talking about? Like "sit" and "play dead"?

Is this a zoo?

You people don't deserve a new driver.

Let me just point out, that in my own experience (benchmarks that were done on RHEL and Slackware, both Linux, with our own server), a 4G/4G split (on a machine with 2GB) reduced the I/O performance by as much as 15%; 3G/1G split reduced the performance by ~10% compared to 64bit code. And we are talking about I/O (both network and disk code) that has little, if any, need for the added 64bit registers.
Furthermore, my own application (that runs purely in kernel mode) is around 30% faster, as I can do all the "long long" math and hashing in a single instruction instead of the usual "instruction 1, add carry, instruction 2", let alone the fact that in "our" high-end configuration, we are 'forced' to use 64bit, as we require huge contiguous buffers and having to remap high memory pages every 1ns just isn't worth the effort.

But, you seem to know everything about everything. You intellect is beyond compare.
You seem to know everything about memory split, high memory, jump buffers (AKA bounce). So who am I to educate you.
Find someone else to spam fight against. You are out of your league here.

[uOpt]

Care to share any numbers of these I/O performance results?

Of course the 4GB/4GB patch on 32 bit i386 Linux split patch reduced I/O performance. There's a complete flush of the TLB on every single system call. That has absolutely nothing to do with what the a 3/1 or 2/2 split do. That is because the 4GB/4GB split patch is a crazy hack, the 3/1 and 2/2 are not.

You realize that a 64 bit kernel has a similar kernel/userland split, too, just higher?

Of course normally 64 bit code is faster than 32 bit, especially if you use > 32 bit integer arthmetic. Nobody questioned that. It is claims that 32 bit can never be faster which just prove the ignorance of the poster.

[arokh]

The few people around here running FreeBSD x64 seem to think 64 bit = double the speed, and they need to run it to get their money's worth. I suggest you educate yourself a bit before demanding nvidia waste time and money on this instead of improving the other platforms first.

[gilboa]

If you bothered to read my original post, before going on rampage, you'd notice that I never claimed that 32bit was slower by design.
I claimed that:
A. 64bit adds additional GP registers.
B. High-memory usage (in-order to access >1GB of memory on 3/1 and >2GB on 2/2) causes a performance hit. (Though I accept, that my point could have been clearer.)

With desktop computers coming preloaded with 1GB of memory, workstation (and gaming machines) with 2GB and server with 4GB, I see little reason to use hacks (PAE) instead of using the real thing. (64bit)

Oh... and BTW, we all do 64bit "math". All file-systems uses 64bit file pointers.

As for sharing numbers, the benchmarks my workplace did before switching to 64bit belongs to them, and them alone.
However, of the top my head,
http://www.anandtech.com/linux/showdoc.aspx?i=2114
http://www.anandtech.com/linux/showdoc.aspx?i=2127
http://www.linuxhardware.org/article.pl?sid=05/02/24/1747228&mode=nocomment
I doubt that you'll have problems finding other credible 32bit vs. 64bit benchmarks.
Mind you, in most of these tests, 64bit beats the living out of 32bit beats with 64bit GCC optimization being years behind 32bit ones. (In my own experience, gcc 4.0 still uses the legacy GP registers [AX, etc] much more then the 'new' 64bit GP registers, so there's a large room for improvement here)

Now, if we can conclude this useless exchange...

[LeonRSV]

The problem is, on my Via kt800 board I even can't get the i386 driver to work. Yes, I'm running i386 (RELASE 6.0) on an amd64 because then I can run openoffice 2 and (well, at least I hoped) the nvidia-driver. But, if I try to enable the nvidia-driver I get this dreaded message:
NVRM: AGP cannot be enabled on this combination of the AMD CPU and OS kernel
NVRM: kernel upgrade recommended.

Really, I'm not thinking running amd64 would double my system's speed, but playing a dvd with a cpu-usage of around 50% on an amd 3500+ (venice core) is a bit stupid isn't it? And no, this has got nothing todo with dma-settings, because it doesn't matter if I run it off dvd or harddisk or just a big mpeg2-file I made of a television-recording. Even playing xvid's makes it running at 50%.

Whe I'm playing a dvd on my multimedia-computer it uses about 10% cpu. This computer is based on a Sempron 2400+ and is running gentoo linux because FreeBSD doesn't support my tv-card. So it's really annoying having it using 50% cpu on your amd64, that's what the problem really is.

[codedragon76]

Okay, they added new optimizations. And algorithms. And logarithms.

Did we actually disagree on anything? Last time I looked you were just sniping on me just for pointing out that memory above 1 GB is not slower (it isn't) and that the 2/2GB boundary (which neither FreeBSD nor Linux have) make things "slower" (which they don't).

I don't see what anything you said has to do with any of that, except that you made that claim that there is no single program running slower in 64 bit mode than 32 bit mode. If you know what a pointer size is it should be pretty obvious to you that I can easily come up with example programs that run slower. How about one of the fancy string representations that have charaters in linked lists?

I never claimed that there would not be a program running slower on 64 bit. I did say it was highly unkikely. I mostly argured with your contention that if you did not know what 64bit was, then you didn't need it. Most business level software, ie databases, image editors etc.. will greatly benefit. Also most gaming applications will see an improvement. Your average gamer has no idea what 64bit means, but the faster floating point math will definately help them see better fps, which they do know about. Therefore the only people who won't see an improvement are internet trollers and people who play solitaire all day.(okay, I am getting a little extreme here, but it does make my point)

[gilboa]

...but the faster floating point math will definately help them see better fps

You are aware the SSE1/2/3 works in 32bit as well?
AMD64 didn't change the basic (lousy) i386 FPU stack/commands.

Games may benefit from the added GP registers... nothing else.
(At least until they pass the 2GB line)

Cheers,