nvidia 32 bit libs on x86-64
ajw1980
Status: Curious
Joined: 30 Aug 2008
Posts: 6
Reply Quote
Hi,

I have a wishlist suggestion. I think sgfxi should ask if it should install the 32 bit nvidia libraries on x86-64. Without them wine doesn't get hardware 3D acceleration. The Freespace 2 port seemed to have the same problems (all I got was a black screen when I launched it without those libraries. I assume it was trying to do software rendering).

The files that are needed and the location they should be installed to can be seen in package list for nvidia-glx-ia32:
packages.debian.org/sid/amd64/nvidia-glx-ia32/filelist

I manually copied those files to the right spot after downloading and extracting the 32 bit installer and wine and freespace2 are working fine.

Andy
Back to top
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 4075
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
If there are standard debian packages to do this, it's no problem, but I'm not going to get into trying to track separate binary packages from nvidia, that's simply not going to happen, it's not maintainable, it might seem interesting short term, but sgfxi is written now to be a long term solution, which means it has to be long term maintainable.

Currently, because nvidia is so well done, it takes me usually about 5 minutes or less each new release to update sgfxi, and if nvidia needs a patch, a few minutes more. That's how it's going to stay too, so any solution needs to be completely smooth and integrated.

I've long held that people who are trying to do what you're doing are making a mistake, and should be running 32 bit, which offers hack free native support for what you want to do.

I faintly remember that there is some way to install both the 32 and 64 bit versions of the nvidia driver during the same install, but I can't really remember the procedure, it's something I thought was too complicated to maintain, but if there's a very easy way to do it safely, I can look into it.

Basically, for this type of highly specialized request: non free driver -> 64 bit -> 32 bit libs -> non free os emulation in wine -> non free games etc, it's pretty much up to the person who wants this setup, which is instantly, and permanently, resolved by using a true 32 bit system, to come up with all the basic code and logic required to make it happen, since it's an issue that is about as close to the bottom of my current list of things to spend time on as you can get re sgfxi.

But if the logic is provided and is safe, reliable, and most important, easily maintainable, there's not a huge reason to not do it.
Back to top
ajw1980
Status: Curious
Joined: 30 Aug 2008
Posts: 6
Reply Quote
Ok.

After taking a look at the nvidia packages a little closer, I have come up with a patch:
:: Code ::

--- sgfxi   2008-08-30 13:26:02.000000000 -0500
+++ /home/ajw/sgfxi   2008-08-30 20:25:14.000000000 -0500
@@ -1875,6 +1875,10 @@
    case $CARD in
       $NVIDIA)
          PKG=0
+         if [ "$ARCH" == '_64' ]
+         then
+            PKG=2
+         fi
          # set the package name, .run is added to it when it's needed
          DRIVER_FILE="NVIDIA-Linux-x86$ARCH-$DRIVER_DEFAULT-pkg$PKG"
          downloadUrl="$NVIDIA_DOWNLOAD_SITE/XFree86/Linux-x86$ARCH/$DRIVER_DEFAULT/"


Well, maybe that was a little easy. When you go to download the drivers, Nvidia always gives you the pkg2 file for x86-64 which already contains the 32 bit compatibility libraries. The installer takes care of the rest.

I wonder why you have the ia32-libs reinstall question?

I would have agreed with you about using 32 bit until a couple of weeks ago, but after doing the benchmarks the performance increase on 64 bit was too much for me to ignore. At this point in time, really most of the 64 bit annoyances have been taken care of. And it won't be long until 4G of RAM is common.
Back to top
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 4075
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
now that's a fine solution, is this complete?

If so, no problem of course adding that patch, but can you just confirm that the patch, and only that, do the trick for you? In other words, make sure to remove all the stuff you installed before, then add this patch, and run sgfxi.

To patch sgfxi and not have it autoupdate, just start it like so: sgfxi -R

plus whatever else you want.

Once you confirm that this works for everything, I'll add it.

I suggest trying the latest, so this: sgfxi -Rco 177.70

Try it with a few drivers just to make sure it works, like:
sgfxi -Rco 96.43.07
sgfxi -Rco 71.86.06
along with the default: sgfxi -Rc

See also sgfxi sticky options, a new dev feature, or just set:
SKIP_RESTART='true'
to avoid accidentally overwriting changes, that's the -R flag.

If that works fine, and everything downloads and appears to work well, and the install works fine, I'll add the patch, but we've used the pkg0 as default now for a long time, I can't even remember what the differences are anymore. I haven't heard any major nvidia issue now using that for quite a while.

The ia32libs was by popular demand, to I think fix some 64 bit wine issue, they needed to be reinstalled after each nvidia install or something, I don't remember, somebody asked for it, so I added it, but I don't use 64 bit except in rare testing cases so I don't really keep up with the 64 bit stuff.
Back to top
ajw1980
Status: Curious
Joined: 30 Aug 2008
Posts: 6
Reply Quote
The 64 bit drivers and 32 bit compatibility libraries are installing (and uninstalling) fine with that patch.

I had already tested the 177.70 driver, but the other drivers worked fine, too. I can't start X with the legacy drivers, but the files were in the right place.

Nvidia tells the package history in pkg-history.txt:
:: Code ::

Package history for NVIDIA-Linux-x86_64-177.70:

NVIDIA-Linux-x86_64-177.70-pkg0: Initial package

NVIDIA-Linux-x86_64-177.70-pkg1: Added precompiled kernel interfaces for:
NVIDIA-Linux-x86_64-177.70-pkg2: Added 32 bit compatibility libraries


I'm not sure that reinstalling the ia32libs really does anything, but I guess it can't hurt. The problem with wine is the 32 bit libraries not being installed.
Back to top
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 4075
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
thanks for the information, any time anyone is willing to do a bit of research and testing, obviously the odds of getting what you want skyrocket.

I'll add that to the script and see if I get any negative feedback, if I do, I'll handle it with an option or something I guess.

This is by the way why sometimes it's worth just putting some feature on hold until a simple solution is created, that is totally hack free.

Again, thanks for the research and testing.
Back to top
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 4075
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
sgfxi 3.9.0: added the pkg2 for nvidia 64 bit patch, cleaned up a bunch of old cruft in the system architecture handling, made it all triggered by BITS global now, deleted legacy CPU and X86 stuff, that was left over from old fglrx junk.
Back to top
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 4075
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
I just wanted to update this. Sgfxi 4.21.xx now also will offer to install ia32-libs to nvidia 64 bit users if the system supports it.

That option is on startup of sgfxi, and is just a choice you can make, it's self evident.

The choice is not seen if your system doesn't support ia32-libs multiarch or if it's already configured and running.
Back to top
Mono
Status: Contributor
Joined: 21 Jun 2012
Posts: 115
Reply Quote
Hi. I was pleasantly surprised to find this feature. However it tells me there is a problem with Apt. I remember I've done things to get 32-bit libs working in the past, but but it gives me the option nonetheless. I'm not sure exactly what packages it wants to install, but I tried this:

:: Code ::
# apt-get install ia32-libs
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Package ia32-libs is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
However the following packages replace it:
  lib32z1 lib32ncurses5 lib32bz2-1.0

E: Package 'ia32-libs' has no installation candidate
# apt-get install ia32-libs-i386
Reading package lists... Done
Building dependency tree       
Reading state information... Done
E: Unable to locate package ia32-libs-i386


:: Code ::
# inxi -bxx
System:    Host: ronin Kernel: 3.11-9.dmz.1-liquorix-amd64 x86_64 (64 bit, gcc: 4.7.3)
           Desktop: Xfce 4.10.2 (Gtk 2.24.18) dm: lightdm Distro: Debian GNU/Linux jessie/sid
Machine:   Mobo: ASUSTeK model: M5A99FX PRO R2.0 version: Rev 1.xx serial: 120700712000098
           Bios: American Megatrends version: 0803 date: 08/15/2012
CPU:       Octa core AMD FX-8350 Eight-Core (-MCP-) clocked at 4008.546 MHz
Graphics:  Card: NVIDIA G73 [GeForce 7600 GS] bus-ID: 01:00.0 chip-ID: 10de:0392
           X.org: 1.14.3 driver: nvidia tty size: 126x46 Advanced Data: N/A for root
Network:   Card: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
           driver: r8169 ver: 2.3LK-NAPI port: a000 bus-ID: 0a:00.0 chip-ID: 10ec:8168
Drives:    HDD Total Size: 280.1GB (23.3% used)
Info:      Processes: 288 Uptime: 40 min Memory: 911.9/7909.3MB Runlevel: 2 Gcc sys: 4.8.2 alt: 4.4/4.7
           Client: Shell (bash 4.2.45 running in xfce4-terminal) inxi: 1.9.14

Back to top
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 4075
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
ia32-libs-i386:i386

this is the package sgfxi checks for, first with:

apt-cache policy ia32-libs-i386:i386

then, if there is an install candidate, with:

apt-get install ia32-libs-i386:i386

we tested this and it was working, though there was also an annoying degree of inconsistency during the dev for what should have been a fairly trivial feature.

During the dev process we discovered some very weird apt behaviors with this multiarch stuff, either bugs or intended, either way it made apt work non predictably.

As always, trying to develop for a system I do not run is a big headache and always takes at least 10x longer than it would if I were doing it locally.
Back to top
Display posts from previous:   

All times are GMT - 8 Hours