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

Newegg Daily Deals

View Poll Results: Where do you stand in regards to AMD64 on BSD?
I use it and would like an nVidia driver! 16 88.89%
I'm considering using it. 1 5.56%
It's too new. I'll wait and see what Intel does. 0 0%
I'm waiting for AMD64-STABLE. 1 5.56%
Voters: 18. You may not vote on this poll

Reply
 
Thread Tools
Old 03-01-04, 12:21 PM   #1
shupienis
Registered User
 
Join Date: Mar 2004
Location: Pittsburgh
Posts: 10
Default FreeBSD on AMD64

First, a word of encouragement for the coders... THANKS for even being aware of FreeBSD! I appreciate the efforts you all have put forth to make my favorite OS work with my favorite video cards!

My question is, are you working on a 64-bit clean version for AMD64 on FreeBSD? I know that there are huge problems since the AMD64 kernel does not support loadable modules (at least "NOT_YET"). This starts a chain of events which includes no Linux (32-bit OR 64-bit) binary compatibility, which I imagine has put a halt to further development.

Might I suggest (as a long-time nVidia buyer -- I recommend your products in all the bid specs I write for my school) taking advantage of the unique opportunity you have to be the first kid on the block with BSD 64-bit clean code for video cards?

It is my considered opinion that AMD64 systems will take off like wildfire, and what with SCO's frivolous lawsuit interest in *BSD will continue to grow.

You might sell a lot of video cards -- certainly enough to justify paying your programmers a few hours' overtime! And who can count the intangible value of all the goodwill you would generate in the BSD/AMD64 community?!

Regards!
// Joe
shupienis is offline   Reply With Quote
Old 03-01-04, 01:50 PM   #2
zander
NVIDIA Corporation
 
zander's Avatar
 
Join Date: Aug 2002
Posts: 3,740
Default

Is there a document describing the overall status of FreeBSD/x86-64? You say that the kernel doesn't currently support loadable modules, do you have (or can point us (as in the forum members) to) more information on this?
zander is offline   Reply With Quote
Old 03-01-04, 02:15 PM   #3
shupienis
Registered User
 
Join Date: Mar 2004
Location: Pittsburgh
Posts: 10
Post

Quote:
Originally posted by zander
Is there a document describing the overall status of FreeBSD/x86-64? You say that the kernel doesn't currently support loadable modules, do you have (or can point us (as in the forum members) to) more information on this?
AMD64 on FreeBSD is currently "Tier 1" which means "fully supported". With apologies to Bill Clinton, however, that depends on what the meaning of the word "fully" is...

The "official" homepage of the FreeBSD/AMD64 Project can be found at:

http://www.freebsd.org/platforms/amd64.html

(which doesn't really say much about the status, except to give the impression that AMD64 is "Fully Supported").


From My Own Experience dep't

I built a dual-Opteron on an MSI KT8 motherboard, with the intention of using it as a mail server, web server and internet gateway for my school. About 1 month later, here I sit, using it at this very moment.

FreeBSD-amd64-5.2-RELEASE
2x Opteron 2400 mp
1GB DDR memory
600 GB software RAID (using vinum, which I managed to compile!)

I've been testing it under load, really beating the crap out of it. It laughs at my feeble attempts to load it. This thing is REALLY fast. Almost fast enough to render Open-GL screensavers in realtime with the default nv driver (Non-GL). But not quite.

The only things that I found missing (other people will find many more) is GL driver support for the nVidia card (5900) and I can't get Sun's JDK to compile. Once I do that, I can compile OpenOfficeOrg 1.1 and have a full workstation for office uses, Graphic uses and audio. All 64-bit and insanely fast.

If a 50-yo old fart like myself can get this far with AMD64, think what the rest of the world can do. I've always been a year or two ahead of the curve. I don't think my acceptance of AMD64 is any different. While Intel plays catch-up, AMD will be pumping out LOTS of systems, and the MoBos will only get better.

Regards
// Joe
shupienis is offline   Reply With Quote
Old 03-01-04, 02:36 PM   #4
zander
NVIDIA Corporation
 
zander's Avatar
 
Join Date: Aug 2002
Posts: 3,740
Default

Tier 1 without support for loadable modules wouldn't help third-party driver development; where could one read up on the technical details behind this limitation?
zander is offline   Reply With Quote
Old 03-01-04, 03:15 PM   #5
shupienis
Registered User
 
Join Date: Mar 2004
Location: Pittsburgh
Posts: 10
Default

Quote:
Originally posted by zander
Tier 1 without support for loadable modules wouldn't help third-party driver development; where could one read up on the technical details behind this limitation?
I agree. I think they are rushing things to call it "Tier 1".

You can google for it but won't find much, even in groups. I think the general problem is that FreeBSD/AMD64 is Very New. It works -- all the big bugs are ironed out. I think the committers decided it was in the best interests of everyone involved to do a MS-style release: As soon as it boots without a blue screen, put it on the store shelves!

I don't disagree totally with this philosopy for bleeding-edge technology -- it allows the curious (like myself) to play with an almost-ready-for-prime-time state-of-the-art set of CPUs to see what the future holds.

The nice thing about AMD64 is it covers my butt: I could always revert to FreeBSD i386 with the same machine and still have a noticeable improvement over the single-cpu P-III /1ghz machine it's replacing. Fortunately, it seems I won't have to. The missing pieces are not show stoppers (vinum would have been, but my persistence paid off) -- they're just "Nice To Have".

There is a broad hint in line 29 of the kernel config (/usr/src/sys/amd64/conf/GENERIC) which says "makeoptions NO_MODULES=not_yet", which leads me to believe that kld modules are planned for the future. But I'm not holding my breath.

I will say this... I "Needed" to use Vinum. It's usually a module. It only took me 3 days to fool around and succeed in compiling it into the kernel as an included, static part of the kernel. An I know NOTHING about C programming.

From what I can gather, if something can be loaded as a module, it can be also be compiled into the kernel. I'll also add that I could NEVER successfully compile a Linux kernel, but my experience with BSD has been quite positive (for a USER-NOT-A-DEVELOPER). The word I've heard from Developers (people other than me who can look at C source code and not get a migraine) is that BSD is easy to write for -- everything is in a standard location, and the existing codebase is Very Well Documented.

Nice chatting!
// Joe
shupienis is offline   Reply With Quote
Old 03-01-04, 03:38 PM   #6
zander
NVIDIA Corporation
 
zander's Avatar
 
Join Date: Aug 2002
Posts: 3,740
Default

Assuming that it is technically possible to link the NVIDIA driver code into the core kernel (it may not be), the solution really wouldn't be realistic from a licensing and/or maintenance point of view. I seriously doubt an effort will be made to support FreeBSD/x86-64 without support for loadable modules (there may be other technical obstacles as well).
zander is offline   Reply With Quote
Old 03-01-04, 03:59 PM   #7
shupienis
Registered User
 
Join Date: Mar 2004
Location: Pittsburgh
Posts: 10
Default

Quote:
Originally posted by zander
Assuming that it is technically possible to link the NVIDIA driver code into the core kernel (it may not be), the solution really wouldn't be realistic from a licensing and/or maintenance point of view. I seriously doubt an effort will be made to support FreeBSD/x86-64 without support for loadable modules (there may be other technical obstacles as well).
I don't see how licensing becomes an issue. Granted I am completely ignorant of C programming, but it seems to me that if (and that's a big IF) the same code can be EITHER a module OR linked into the kernel, then it wouldn't be fundamentally different from being ONLY a module, as far as licensing goes. I haven't tried it but I wonder if I could include the 32-bit driver into my next 32-bit kernel build. I guess it would take me 5 minutes to find out!

It doesn't appear to me to be necessary to make the driver a part of the core kernel to be distributed with the release. In fact it is my understanding that there are one or two kernel modules that require downloading from a commercial site after validating and jumping through whatever flaming hoops the IP owner insists upon, whether the code is to be used as a module or as part of a monolithic kernel.

Oh! I just noticed something... are we talking about the same CPU? I'm using AMD Opterons, not Intel anything... I'm saying AMD64 and you're saying x86-64. Are they two different things, or are they different names for the same thing? Please forgive my ignorance, I'm new to this whole 64-bit thing.


Of course if I boot with the 32-bit OS, everything is perfect. But I'd rather not have to dual boot to run a screensaver. Or a video editing program. But, try as I might, I can't make any 32-bit code execute with the 64-bit kernel -- if I could, then the problem would be moot!

Thanks for your patience and civility with me!
// Joe
shupienis is offline   Reply With Quote
Old 03-01-04, 04:07 PM   #8
zander
NVIDIA Corporation
 
zander's Avatar
 
Join Date: Aug 2002
Posts: 3,740
Default

We're talking about the same platform, I just prefer x86-64 over amd64 since it describes the architecture better and seems more reasonable considering Intels latest offerings. I'm not sure if the kernel component of the NVIDIA driver could be linked into the kernel proper (it's rather large), but even if it was possible from a technical and legal point of view, I wouldn't consider it a viable solution.
zander is offline   Reply With Quote

Old 03-01-04, 07:58 PM   #9
shupienis
Registered User
 
Join Date: Mar 2004
Location: Pittsburgh
Posts: 10
Thumbs up

Quote:
Originally posted by zander
We're talking about the same platform, I just prefer x86-64 over amd64 since it describes the architecture better and seems more reasonable considering Intels latest offerings. I'm not sure if the kernel component of the NVIDIA driver could be linked into the kernel proper (it's rather large), but even if it was possible from a technical and legal point of view, I wouldn't consider it a viable solution.
But isn't the upcoming Intel XEON-64 supposed to use a completely different instruction code from the AMD46? I would suspect that they would also have incompatible pinouts, requiring different sockets and support chipsets, as well.

Back to the kernel, you raise a key issue. Developers vs. Users.

The good developer wants to make clean, compact code, no matter how long it takes -- even if it means "never".

The user wants it NOW, regardless of how big, ugly and kludgy it is. Mr Gates owes his billions to realizing that, and acting appropriately on it.

I would presume that best practice lies somewhere in between the two conflicting mindsets.

For my part, I'd be perfectly fat, dumb and happy compiling some huge blob of code into my kernel. It's already 6+ meg -- what's a few more meg going to hurt? You see, for ME (I don't speak for anyone else), for ME, compiling a large piece of code into MY kernel IS viable. For me. Not necessarily for anyone else. Even if it makes my dog go bald and the neighbor's cat start singing opera.

As I recall from a few years ago, space in the Linux Kernel is precious because it has to fit on a floppy (or was that overcome several versions ago?), but BSD has no such limitation that I am aware of.

Here's an interesting thought/question... OS-X for the Mac G5. The G5 is a 64-bit extension to a 32-bit architecture, just like the current AMD64 and the proposed future Intel Xeon-64. OS-X is a BSD kernel. What's the 64-bit driver status there?

Warmest regards!
// Joe
shupienis is offline   Reply With Quote
Old 03-01-04, 08:20 PM   #10
SnapIT
Registered User
 
Join Date: Jun 2003
Posts: 154
Default

Quote:
Originally posted by shupienis
But isn't the upcoming Intel XEON-64 supposed to use a completely different instruction code from the AMD46? I would suspect that they would also have incompatible pinouts, requiring different sockets and support chipsets, as well.

Back to the kernel, you raise a key issue. Developers vs. Users.

The good developer wants to make clean, compact code, no matter how long it takes -- even if it means "never".

The user wants it NOW, regardless of how big, ugly and kludgy it is. Mr Gates owes his billions to realizing that, and acting appropriately on it.

I would presume that best practice lies somewhere in between the two conflicting mindsets.

For my part, I'd be perfectly fat, dumb and happy compiling some huge blob of code into my kernel. It's already 6+ meg -- what's a few more meg going to hurt? You see, for ME (I don't speak for anyone else), for ME, compiling a large piece of code into MY kernel IS viable. For me. Not necessarily for anyone else. Even if it makes my dog go bald and the neighbor's cat start singing opera.

As I recall from a few years ago, space in the Linux Kernel is precious because it has to fit on a floppy (or was that overcome several versions ago?), but BSD has no such limitation that I am aware of.

Here's an interesting thought/question... OS-X for the Mac G5. The G5 is a 64-bit extension to a 32-bit architecture, just like the current AMD64 and the proposed future Intel Xeon-64. OS-X is a BSD kernel. What's the 64-bit driver status there?

Warmest regards!
// Joe
There is no Xeon 64 so i have no clue what you are talking about...

Perhaps you mean the Itanium? it has been out for five years, the IA64-II is probably what you mean, this is not a processor for even the mainstream generation of servers, it is EXPENSIVE and from what i have seen performs pretty badly unless you restructure every single line of code, Intel does not have the authority to make companies do that anymore...

Or perhaps you mean the Ia32-e? The cpu that implemented some of the parts of the AM-64 arch but forgot the most important part?

There are kernels for AM-64 for all versions of linux and BSD that are stable...

It would be an interesting question if it wasn't for the fact that the G5 uses a 32bit interpreter to execute the code, the Intel Xeon-64 will never exist and the AMD64 have had it's own kernel for BSD for months...

Regarding the linux kernel, that is a warning you get if your kernel exceeds 1.44 mb (in 2.4 kernels, in 2.5 and later you will not even get the warning) that was it... so, wrong on that too...

So you have absolutely no clue about any of this, i suggest you read before you write...
SnapIT is offline   Reply With Quote
Old 03-01-04, 09:10 PM   #11
shupienis
Registered User
 
Join Date: Mar 2004
Location: Pittsburgh
Posts: 10
Default

Quote:
Originally posted by SnapIT
There is no Xeon 64 so i have no clue what you are talking about...

Perhaps you mean the Itanium? it has been out for five years, the IA64-II is probably what you mean, this is not a processor for even the mainstream generation of servers, it is EXPENSIVE and from what i have seen performs pretty badly unless you restructure every single line of code, Intel does not have the authority to make companies do that anymore...

Or perhaps you mean the Ia32-e? The cpu that implemented some of the parts of the AM-64 arch but forgot the most important part?

There are kernels for AM-64 for all versions of linux and BSD that are stable...

It would be an interesting question if it wasn't for the fact that the G5 uses a 32bit interpreter to execute the code, the Intel Xeon-64 will never exist and the AMD64 have had it's own kernel for BSD for months...

Regarding the linux kernel, that is a warning you get if your kernel exceeds 1.44 mb (in 2.4 kernels, in 2.5 and later you will not even get the warning) that was it... so, wrong on that too...

So you have absolutely no clue about any of this, i suggest you read before you write...
Thank you for your informative reply. I'm a proud owner of a dual-opteron BSD box, which is in sad need of a working 64-bit nVidia driver.

As to Intel, perhaps I was misled by the news items I read last week about Intel announcing a future Xeon-based CPU with 64-bit extensions.

Perhaps when you read my initial question, you missed what I asked, so here it is again, in a nutshell:

Is there any work going on at nVidia to provide an AMD64 64-bit video driver which could be compiled into the 5.2 or -CURRENT 64-bit FreeBSD kernel? (That kernel does not support modules, so Linux-compatibility mode and kld modules are out of the question.)

Thanks again for your information. You helped me see more clearly.

Regards!
// Joe
shupienis is offline   Reply With Quote
Old 03-01-04, 09:37 PM   #12
SnapIT
Registered User
 
Join Date: Jun 2003
Posts: 154
Default

Quote:
Originally posted by shupienis
Thank you for your informative reply. I'm a proud owner of a dual-opteron BSD box, which is in sad need of a working 64-bit nVidia driver.

As to Intel, perhaps I was misled by the news items I read last week about Intel announcing a future Xeon-based CPU with 64-bit extensions.

Perhaps when you read my initial question, you missed what I asked, so here it is again, in a nutshell:

Is there any work going on at nVidia to provide an AMD64 64-bit video driver which could be compiled into the 5.2 or -CURRENT 64-bit FreeBSD kernel? (That kernel does not support modules, so Linux-compatibility mode and kld modules are out of the question.)

Thanks again for your information. You helped me see more clearly.

Regards!
// Joe
Actually, i have to admit that i have not gone into any great depths with the AM-64 Current kernel because of lack of time, but i have a system that i intend to use it on, but the non support of modules sounds horrible, that means that only an integral part of the kernel can be used for drivers...

IE that means that every driver has to fit inside EBDA too, which would suck for servers with RAID, LVM, and several GB E drivers along with standard drivers and filesystems... it would be impossible to implement...

I have to look into this a bit more, but it has to be a temp solution...

The CPU you are thinking of is probably the ia32-e, it does not implement any of the per page permissions, so i consider the ia32-e a second rate CPU...

Actually rereading Theos mail makes me realize that it will not only not implement any 64-bit permissions, it will not implement any 32bit permissions either... WIDE OPEN...

Hopefully they are working on that though... Theos cpu was pre-production so maybe some of it will be implemented in the finished work, time will tell...
SnapIT 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
Reasons Why You Should Not Use FreeBSD News Archived News Items 0 06-02-12 10:40 AM
Why Should You Use FreeBSD? Here's Some Reasons News Archived News Items 0 05-31-12 02:10 PM
nvidia-driver-295.49 is highly unstable on FreeBSD 9.0 with 9400GT card yurivict NVIDIA FreeBSD 0 05-28-12 01:14 PM
FreeBSD 9 Release with Nvidia 550 Ti configuration issues goga NVIDIA FreeBSD 0 05-23-12 09:34 AM
NVIDIA drivers 302.11 for Linux, FreeBSD and Solaris News Archived News Items 0 05-19-12 12:20 PM

All times are GMT -5. The time now is 10:54 AM.


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