64bit support for nvidia and creative

I guess I'll wait more to make this new video card purchase. I'm still more likely to go ATi, but let's see :)

none
 
adamk said:
Errr.. You're a little misinformed here.

xf86-video-ati (aka, the 'radeon' driver in this case) supported AtomBIOS first.

radeonhd developers did not want AtomBIOS at all. That's why radeon/ati supported it first. AMD wanted to have AtomBIOS as fallback in radeonhd, as far as I understood it and pushed the developers to support it. Finally they decided that they want to be nice to AMD and implemented it. Everyone was happy, except radeon/ati developers.

While 'radeonhd' was the first to support 2D in r500 cards (*not* through AtomBIOS) the same functionality was quickly added to the 'radeon' driver.

Not quite the same. radeonhd is whole lot more efficient than radeon using 2D thanks to its command submission architecture. You can see it when you compare them both directly on your desktop. radeonhd is faster and smoother than radeon on my hardware.

As for me, I prefer the 'radeon' driver simply because I've been using it for years on older GPUs and it works fine. I use dual screen all the time, and regularly switch VTs without issue.

I tried 3 different ATI cards. Every single of them works better when I use radeonhd. I can understand that everyone chooses the driver which works best on their own hardware. When you choose radeon and it works better than radeonhd, it's ok, of course.
 
Your post got me thinking... I hadn't actually tried radeonhd in a while, so I did a quick comparison of 'radeon' and 'radeonhd' with gtkperf on an x1950. Same DRM version, same Xorg version. This is basically the current ports tree with this patch to bring Xorg up to 7.4: http://pastebin.ca/raw/1296801 . DRM was pulled from git just two days ago. I just switched from one driver to the other in my xorg.conf file between tests. The Test rounds was set to 1000:

With radeon
Code:
GtkPerf 0.40 - Starting testing: Tue Dec 30 20:26:34 2008 

GtkEntry - time:  0.31
GtkComboBox - time:  6.41
GtkComboBoxEntry - time:  5.40
GtkSpinButton - time:  0.93
GtkProgressBar - time:  0.30
GtkToggleButton - time:  1.60
GtkCheckButton - time:  1.51
GtkRadioButton - time:  2.03
GtkTextView - Add text - time: 37.72
GtkTextView - Scroll - time: 54.80
GtkDrawingArea - Lines - time: 31.33
GtkDrawingArea - Circles - time:  5.55
GtkDrawingArea - Text - time: 13.56
GtkDrawingArea - Pixbufs - time:  0.79
 --- 
Total time: 162.24

With radeonhd:

Code:
GtkPerf 0.40 - Starting testing: Tue Dec 30 20:33:33 2008

GtkEntry - time:  0.37
GtkComboBox - time:  6.28
GtkComboBoxEntry - time:  5.32
GtkSpinButton - time:  0.82
GtkProgressBar - time:  0.40
GtkToggleButton - time:  2.07
GtkCheckButton - time:  1.47
GtkRadioButton - time:  2.12
GtkTextView - Add text - time: 33.44
GtkTextView - Scroll - time: 53.23
GtkDrawingArea - Lines - time: 39.57
GtkDrawingArea - Circles - time:  4.74
GtkDrawingArea - Text - time: 11.96
GtkDrawingArea - Pixbufs - time:  0.77
 --- 
Total time: 162.55

So almost the exact same :) In the end, you are right: everyone should be able to choose whatever driver they feel works best for them.

I'm curious if there are any other benchmarking utilities anyone can think of available via the ports tree?

Adam
 
Apart from binary blob there is open source nouveau driver. It still lacks up to date DRM support on BSD side. There is even an old snapshot available through pkgsrc and a patch against src/sys/ with a few tweaks aplicable to freebsd before DRM was updated.
 
Contrary to popular belief, Creative did write a X-Fi compatible driver for FreeBSD that supposedly worked for 7.x. I never tried it though (I switched my desktop OS from FreeBSD over to Linux to Vista, and now I'm going back to FreeBSD because there are workarounds for the games I want to play again). See: http://www.phoronix.com/scan.php?page=article&item=990&num=1. I believe a compatible version is available via audio/oss.

Then some dev's coded up the driver in ALSA, and I need to reprod them to use OSS because apparently someone missed the note about ALSA having an OSS compatibility shim; Linux's implementation of OSS without vchan support shouldn't be a shortcoming for other OS'es which implement OSS properly :).

That's what one gets for prodding the Creative folks at least (huzzah!).

Also, I've started inquiring about what's needed to post a bounty and donate towards fixing up the nVidia feature request items. These should be done not just for nVidia but for ATI, Intel, and other various 64-bit driver support which we need moving forward for FreeBSD to remain a worthwhile desktop and server platform.
 
gcooper@ said:
Also, I've started inquiring about what's needed to post a bounty and donate towards fixing up the nVidia feature request items. These should be done not just for nVidia but for ATI, Intel, and other various 64-bit driver support which we need moving forward for FreeBSD to remain a worthwhile desktop and server platform.

Ahhh, maybe you know, then, how those features would benefit the current ATI and intel drivers?

Adam
 
It still doesn't explain specifically how the current open source drivers would benefit from those changes... Besides, would you actually expect nvidia to say "These changes, outlined below, will only benefit our ability to port our drivers to FreeBSD/amd64, but we'd like the FreeBSD developers to spend their time implementing them anyway?"

I'm not saying they aren't good changes. I'd just like a technical explanation, preferably from someone who understands how the open source drivers work, as to how those changes are going to benefit drivers open source drivers for FreeBSD/amd64 that are already available. Otherwise, there really is no reason to believe that's the case.

Adam
 
AFAIK those features aren't in 6, only 7 and 8. Since 6 is still supported that might be the reason why it's currently not being used in the ATI driver.
 
SirDice said:
AFAIK those features aren't in 6, only 7 and 8. Since 6 is still supported that might be the reason why it's currently not being used in the ATI driver.

those features that would make a amd64 nvidia driver possible are already in 7 code ? or 8 ?

so the driver is just a matter of time and nvidia efforts (or lack) ?

none
 
FreeBSD 7.0.2 x86 ( Problems ) - thread merged

Hello, I'm Dimitar and i have some questions and i hope i write in the right forums :)

My English is not good but i hope that you will understand me and help me.

I am working with FreeBSD 7.0.2 x86 and i have problem with video drivers. I have nVIDIA GeForce 9800 GT (512MB) and have downloaded drivers from http://www.nvidia.com/object/freebsd_173.08.html.
But when i started installing my terminal it says : error this drivers are not supported for FreeBSD 7.x version.
Please help me to fix this problem. Now i am using Vesa drivers but.. i don't know my resolitions.. and my shrift sux... This is big problem for me... Please give me some help.
Write here or dhtodorov@gmail.com.

Thank you !
 
1. are you familiar with the ports tree, which has a perfectly working NVIDIA driver for 32-bit FreeBSD 7 (nvidia-driver-180.29 )?

2. do you have compat5 installed, which NVIDIA needs (compat5x-i386-5.4.0.8_9)?
 
Something like "x86" doesn't identify a 64-bit system. Anyway, there are no NVIDIA drivers for 64-bit FreeBSD. If you don't really need a 64-bit system (in other words, if you don't need more than 3 GB RAM), go with 32-bit FreeBSD.

(thread "FreeBSD 7.0.2 x86 ( Problems )" merged with this one)
 
Is anyone working on the mmap task or will there be anyone doing so for google summer of code? I may have a go at it if not.
 
Zander Nvidia corporation said:
FreeBSD/amd64 presents a different environment to the driver, (some of) the workarounds employed on FreeBSD/i386 do not work or are insufficient on this platform. As stated before, it is our belief that the NVIDIA UNIX graphics driver stack cannot work reliably on FreeBSD/amd64.
NVNews
 
Zander Nvidia Corporation said:
There's really nothing NVIDIA can do at this point. As I said earlier, the NVIDIA UNIX graphics driver team is not staffed to take on FreeBSD kernel development work at this time, and it doesn't make sense to speculatively develop for the missing pieces - especially if there's no telling if/when these missing pieces will fall into place (I don't have any information you don't have with respect to this). As stated before, the remaining features (especially the mmap() interface update(s)) are considered prerequisites for a FreeBSD/amd64 driver port. FWIW, I don't think it would take very long to provide a BETA driver for FreeBSD/amd64 if the necessary kernel support was available.
Post #382
 
What gets me is people saying their is a lack of customer base for the drivers to be developed.
If you look at the forum topic FreeBSD AMD 64 driver, you will see 385 posts and 115,000+ views. Not only is this an extreme amount of posts for a single topic but is a large amount of views as well.
I havent seen threads this large for conficker on security forums.

It appears that this is a very important issue and many people are actively waiting somewhat impatiently.
 
Back
Top