A heads up:

We have been advised that NVIDIA expects soon to end support for CUDA and similar GPGPU software on 32-bit Windows. When that happens, Manifold also will no longer support GPGPU on 32-bit Windows. CPU parallelism will continue to be supported in 32-bit Windows but to be able to utilize GPU parallelism 64-bit Windows will be required.

Will you also be dropping GPGPU on 32-bit Manifold 9 running under 64-bit Windows?

Yes, as that is the same thing. 32-bit Manifold runs in a 32-bit Windows context that 64-bit Windows opens, as it does whenever you launch a 32-bit program within 64-bit Windows. That's a 32-bit world so everything has to be 32-bit in that context. Since there will be no 32-bit NVIDIA CUDA or other drivers, there will be no GPGPU in that 32-bit application.

Of course, they are not the same thing.

But it is good to know that the same applies. Thank you.

Of course, they are not the same thing.

? How could 32-bit Manifold running in 32-bit Windows be different?

At the risk of... bla bla bla. (But the risk of leaving confusion on the table seems slightly worse.)

D: There will soon be no CUDA for 32-bit Windows, only for 64-bit Windows.

T: How about 32-bit CUDA under 64-bit Windows?

D: Same, because that is the same thing. [As I read it: 32-bit Windows is the same thing as 32-bit software running under 64-bit Windows. Not.]

T: OK. But...

D: Huh?

For example, it could be that while NVIDIA is planning to drop support for 32-bit Windows, it might continue to include nvcuda32.dll with its drivers for 64-bit Windows. Just as it does now. So that 32-bit CUDA code would continue to run in a 64-bit environment. I don't know.

On the other hand, I gather that compiling 32-bit code has been dropped for CUDA Toolkit 9.x under Visual Studio >=2017. Not sure about the details. Maybe Manifold is making that move, thus the change?

For example, it could be that while NVIDIA is planning to drop support for 32-bit Windows, it might continue to include nvcuda32.dll with its drivers for 64-bit Windows. Just as it does now. So that 32-bit CUDA code would continue to run in a 64-bit environment.

The above indicates a misunderstanding. The key learning in my comment comes after that first "Yes, it is the same thing." sentence:

32-bit Manifold runs in a 32-bit Windows context that 64-bit Windows opens, as it does whenever you launch a 32-bit program within 64-bit Windows. That's a 32-bit world so everything has to be 32-bit in that context.

There is no such thing as 32-bit CUDA code running in a 64-bit environment, not now and not in the future. 32-bit CUDA code only runs within a 32-bit environment. nvcuda32.dll is not a driver for 64-bit Windows. It is a 32-bit driver that is used exclusively within 32-bit Windows.

Whenever you launch 32-bit code, whether that is a driver or an application or whatever, it may seem to run within 64-bit Windows but in reality it is running within 32-bit Windows. It is part of the cleverness of 64-bit Windows that people think their 32-bit applications are "running in 64-bit Windows" when in reality they are running in 32-bit Windows.

When Microsoft introduced 64-bit Windows they knew perfectly well there were no applications that could run in 64-bit Windows. So they put effort into a key feature within 64-bit Windows that enables it to more-or-less seamlessly launch 32-bit Windows as a host environment for 32-bit applications.

That is one reason why when 32-bit applications run they run with all the unreliability and other issues attendant to 32-bit Windows. Running a 32-bit application (or driver or whatever...) means you are running 32-bit Windows. It literally is the same thing.

I should note that exploiting widespread ignorance about how that works is an essential part of deceptive marketing practices. For example, ESRI for many years would tell people "we support 64-bit Windows" in a way that gave the impression their products could actually run 64-bit. Nonsense. Their products remained 32-bit products which ran within 32-bit Windows even if your machine was loaded with 64-bit Windows, and thus their 32-bit products had all the limitations of 32-bit memory and significantly lower reliability of 32-bit Windows.

When you launch 32-bit software in a Windows installation you launch that within 32-bit Windows, whether or not what you have loaded on your machine is a 64-bit Windows operating system. Conceptually, it is somewhat like running a PC application on a Mac, where a virtual machine emulator launches Windows to run that application. In this case, it is just 64-bit Windows seamlessly launching a 32-bit Windows instance to allow your 32-bit code to run.

You are confusing the 32-bit subsystem under 64-bit Windows with 32-bit Windows itself.

They are absolutely not the same thing.

Answer this simple question: will nvcuda32.dll [or nvcuda.dll for 32-bit] continue to exist under 64-bit Windows, and if so, will 32-bit Manifold 9 continue to use it?

That is all that matters.

(If you don’t know, just say you don’t know, that’s fine.)

You are confusing the 32-bit subsystem under 64-bit Windows with 32-bit Windows itself.

They are absolutely not the same thing.

They absolutely are the same thing for the purposes of running 32-bit applications. There are nuances, sure, but none at the level that either a) change the key learning or b) can be understood without many, many pages of details, which in the end don't matter.

I don't like writing educational essays that cover every possible ways in which somebody might say "Aha! No! you're wrong... they are not the same, because when 32-bit Windows installs in the System dialog it reports '32-bit Windows...' " What you refer to as "the 32-bit subsystem" is indeed 32-bit Windows.

I'm puzzled why you think that to be contentious, or that it could reasonably be expected to be anything else. Surely you realize that modern 32-bit applications, with all their dependency on zillions of 32-bit Windows features, could not run in such a "subsystem" if it were anything less than the real thing, 32-bit Windows?

Consider the common-sense aspect of it as well: what do you think would be easier for Microsoft to do in terms of providing a 32-bit Windows environment within which 32-bit Windows applications could run... would it be easier for Microsoft to simply launch 32-bit Windows and thus automatically get everything right, or should Microsoft spend infinite billions creating a "32-bit subsystem" emulator that is not 32-bit Windows but which hopes to get every fine detail right, just like 32-bit Windows, without actually being 32-bit Windows?

will nvcuda32.dll [or nvcuda.dll for32-bit] continue to exist under 64-bit Windows

No. When NVIDIA ends support for 32-bit Windows they no longer will create and provide 32-bit dlls for 32-bit Windows. No such 32-bit dlls will exist at all.

(Regarding just the last para.)

Did you mean, “... no longer will create and provide 32-bit dlls for 64-bit Windows”?

If so, that’s a complete answer, and it could have gone in your first post.

That is all I have been asking, throughout.

(And the idea of 32-bit Windows and 32-bit WOW being “the same thing” is still just silly. Think only of the massve compatibility framework. No don’t.)

no longer will create and provide 32-bit dlls for 64-bitWindows”?

Tim, you are phrasing that in a "have you stopped beating your wife?" manner. The way you phrase it is false, because it forces someone to agree with the conceptual blunder upon which you appear to insist.

NVIDIA has not now, nor have they ever provided 32-bit dlls for 64-bit Windows. In the past (and until end of life takes effect) NVIDIA has provided 32-bit dlls ONLY for 32-bit Windows.

it could have gone in your first post.

No, because I don't make such errors. The phrase I used:

NVIDIA expects soon to end support for CUDA and similar GPGPU software on 32-bit Windows

...is exactly correct. A different way of saying the same thing, if accompanied by sufficient discussion to not confuse consumers, would be "NVIDIA will no longer provide 32-bit CUDA .dlls",

...but to imply that NVIDIA ever provided 32-bit .dlls for 64-bit operating systems would be just plain wrong.

Speaking in terms of .dlls would also be less helpful because it mentions a specific mechanism, which consumers usually don't understand, as opposed to the global statement I made. I grant that not everybody understands the global statement, either, but your odd are better keeping it simple and general than getting into specific technical mechanisms that even fewer people will grasp.

What NVIDIA actually provides, for example, as far as most consumers are concerned, is a small .exe which when launched proceeds to download and install all the various drivers your particular NVIDIA GPU card requires, with CUDA being bundled in.

(And the idea of 32-bit Windows and 32-bit WOW being “the same thing” is still just silly. Think only of the massve compatibility framework. No don’t.)

Missed that part. You must have missed my prior comment:

They absolutely are the same thing for the purposes of running 32-bit applications. There are nuances, sure, but none at the level that either a) change the key learning or b) can be understood without many, many pages of details, which in the end don't matter.

Our task here is not to confuse people with irrelevancies. NVIDIA does not create 32-bit .dlls for WOW, they create them for 32-bit Windows. It is, indeed, the same thing for the purposes of running 32-bit applications. Again, the common sense thing... if it wasn't it wouldn't work as well as it does.

(And the idea of 32-bit Windows and 32-bit WOW being “the same thing” is still just silly. Think only of the massve compatibility framework. No don’t.)

I find the above such a disservice to less expert users I would ask you to do this: please launch a different thread to explain how WOW works in a way that guides use of 32-bit software. Your task is to come up with something that can be followed by an average user and which guides that user as well as the statement "When they stop supporting it for 32-bit Windows it is gone for all 32-bit uses."

I don't know any average user that has been well-guided by the full details, necessarily intricate, of how 32-bit Windows applications run in 64-bit Windows. Such discussions do not guide people as well as the simple notion of running 32-bit Windows within the 64-bit Windows. If it don't run in 32-bit Windows it don't run in Windows within Windows on a 64-bit system either.

If you can capture that same notion for less expert readers within a precise, fully-nuanced discussion of Windows on Windows, you'd be doing the world a service.

Edited... No, on second thought, don't bother. Our job in this forum is not to cover all of Windows. It's to convey the simple issues guiding use and deployment, which this thread beats to death.

Here’s another question that might sharpen the issue—also important in its own right of course.

Will 32-bit Manifold 8 (NB eight) continue to utilise CUDA with future NVIDIA drivers?

If so, why. If not, why not.

Explaining this should really focus the question.

Will 32-bit Manifold 8 (NB eight) continue to utilise CUDA with future NVIDIA drivers?

If so, why. If not, why not.

The answer follows from my post:

We have been advised that NVIDIA expects soon to end support for CUDA and similar GPGPU software on 32-bit Windows. When that happens, Manifold also will no longer support GPGPU on 32-bit Windows.

When "future NVIDIA drivers" no longer support 32-bit Windows, there will be no 32-bit NVIDIA drivers. At that time, no software of any kind, including video converters, games, hydrodynamic simulators, Release 8, Release 9, etc., etc., that runs 32-bit will be able to use CUDA.

Why not? Because the 32-bit NVIDIA CUDA code they require to run CUDA will not exist.

Look, from NVIDIA's perspective, a perspective shared by many, it is not a big deal. Betting on CUDA use within 32-bit Windows is like putting wooden wagon wheels on your Ferrari. It doesn't make sense. If whatever you are doing requires CUDA performance you should be running 64-bit anyway.

It's true some people are stuck running 32-bit legacy systems, but NVIDIA does not want to hold back progress in GPGPU because some people cannot upgrade to what has long been the standard for such work.

That does not answer the question Dimitri.

(Read it again.)

Will 32-bit Manifold 8 (NB eight) continue to utilise CUDA with future NVIDIA drivers?

I'm genuinely puzzled... the answer to your question above is:

If NVIDIA does not provide 32-bit drivers in the future, then 32-bit Manifold Release 8 cannot use such drivers. The reason is that they will not exist. Manifold Release 8 cannot use something which does not exist.

How does the above not answer your question?

And FFS, I don’t run any 32-bit systems!

I just want a straight answer!

Can we please have Adam??

I just want a straight answer!

You've received that straight answer: NVIDIA is ceasing CUDA support for 32-bit Windows. No software which runs in 32-bit Windows will be able to use CUDA after that end-of-life.

Additional information that should not need to be explicitly stated:

1. We are talking about future editions of CUDA. Obviously, versions published in the past will not disappear, just like Windows XP has not automatically disappeared.

2. When you run a 32-bit application within a 64-bit Windows system, you are actually running that application within an instance of 32-bit Windows. Therefore, all requirements for running the application in 32-bit Windows apply. For example, if the application utilizes CUDA you must have NVIDIA drivers for 32-bit Windows. When NVIDIA ceases support for 32-bit Windows, you will no longer have those drivers and thus you will not be able to run that 32-bit application in any situation. You will not be able to run that 32-bit application on a "native" 32-bit Windows system and you will not be able to run that 32-bit application within a 32-bit Windows session launched by 64-bit Windows.

I'm not sure how many different ways such a simple and straight answer can be phrased. The point of this is to provide a very, very simple and direct statement: NVIDIA is ending 32-bit support for CUDA. That's it. Done. No 32-bit CUDA anywhere. No need to play semantic games, and no need to confuse the innocent.

Tim, a lot of people read this forum who do not have your technical skills. You are doing them a disservice by confusing the issue. Are there nuances? Sure. None of them have any bearing on this issue. When NVIDIA ends support for 32-bit Windows that ends 32-bit support, period.

Apologies for being late to the thread. (Ugh.)

Here is what is going on:

The world is now mostly 64-bit so CUDA is normally used from 64-bit applications. In order to support CUDA for 32-bit applications, NVIDIA have to go an extra mile, this support does not come for free.

CUDA in 32-bit applications is already subject to stricter limitations than in 64-bit. Not only that, but some tools used in CUDA development (including those that we use) are also slightly different between the environments, with 32-bit versions not being updated to have all the latest features that 64-bit versions have. This has been the case for several years now.

Eventually, NVIDIA will likely cease to support CUDA in 32-bit applications. At first this will affect tools (new tools will not support developing for 32-bit, but already created 32-bit applications using CUDA will continue to be able to use it and everyone who'd like to continue to develop 32-bit applications using CUDA will be able to do so by using previous versions of NVIDIA tools without the latest features). Then this will affect the drivers (32-bit applications will ask the driver 'could you please run this code on GPGPU for me?' and the driver will say 'no, I don't support that'). We will not be able to use GPGPU (using CUDA) in 32-bit at the second stage. Whether or not we will continue allowing to use GPGPU in 32-bit in the first stage is an open question. We might indeed decide to drop it. That would be similar to NVIDIA: if you want to use GPGPU from 32-bit, use a previous version of the tool (in our case, a previous version of 9 / Viewer + all versions of 8 are 'previous').

Hope this clears it up a bit.

That is very clear and helpful, thanks. It clears up not only development options for Manifold 9, but also the eventual implications for Manifold 8.

Whether or not we will continue allowing to use GPGPU in 32-bit in the first stage is an open question. We might indeed decide to drop it.

For what it is worth, I doubt that many users would object if you decided to drop CUDA from all 32-bit versions of Manifold 9 from now on.

(1) It would be clear. (2) 32-bit Manifold now has limited usage, mainly for compatibility workarounds and some use on mobile devices. Generally not for high performance. (3) 32-bit CUDA will remain available in Manifold 8 for the time being (until the eventual stage 2). (4) It sounds as if making the break would simplify development at least a bit, allowing engineering efforts to be concentrated where the results will really be used.

Others might see it differently.