That’s a good point.
Does OpenGL even have 64bit support?
I thought that was something coming out in OGL 4?
And just to clarify, this is a Windows CPU virtual memory (VM) limitation. 32-bit Windows by default splits VM 2GB/2GB user/kernel, so you get at most 2GB of VM to play with in your app (note this is virtual memory, not physical memory).
On Linux, process virtual memory is typically split 3GB/1GB user/kernel on a 32-bit machine, so you get 3GB tops by default per process. Though you can tweak this (e.g. 3.5GB/0.5GB).
This VM address space limit on 32-bit OSs/CPUs is an issue regardless of how much physical memory you have installed on the box.
Incidentally, this annoying limitation is what often pushes folks onto a 64-bit OS/CPU. All of this CPU VM limit nonsense just goes away. On a 64-bit box, your maximum VM space bumps up to over 1TB, well over the amount of physical memory folks have installed nowadays.
Yes, because OpenGL keeps a copy of your texture data. And lots of textures (or a few HUGE textures) can greatly increase the virtual memory address consumption of your process, along with other data, library data/code, program address space, etc.
If you’re on Linux, run “top” to check out your process and see how much virtual memory it is consuming. Make sure it doesn’t get anywhere near 3GB on 32-bit Linux. On Windows, run whatever the equivalent tool is (???) and make sure you app doesn’t ever come close to 2GB. If it does…boom! Your app’s history. If you haven’t ever run such a tool, you’ll likely be shocked at how much VM its eating.
Definitely! If you mean support for 64-bit OSs/CPUs (referring to Alfonse’s 2GB CPU VM mention), we’ve been running NVidia OpenGL on 64-bit Linux for like 6 years now. ATI has had 64-bit Linux support for many years as well. This is not just old news, but ancient history now. 64-bit OSs/CPUs get rid of the 2-4GB CPU memory limitation per process.
I thought that was something coming out in OGL 4?
I think you’re mixing up apples and oranges. “That” 64-bit support is support for doubles (float64 values) on the GPU.
Then how to upload huge data into texture normally?
Then how to upload huge data into texture normally?
You don’t. You work around it in other ways.
I have ever thought to use the method of texture compression. Maybe it is the only way to solve this problem, but I are wondering whether the data set that the format of vexel is stored as unsign byte can be compressd?
Forgive me if I’m mistaken, but are you sure you are not talking about voxels?
I thought vexels was for vector art rasterizations?
Definitely! If you mean support for 64-bit OSs/CPUs (referring to Alfonse’s 2GB CPU VM mention), we’ve been running NVidia OpenGL on 64-bit Linux for like 6 years now. ATI has had 64-bit Linux support for many years as well. This is not just old news, but ancient history now. 64-bit OSs/CPUs get rid of the 2-4GB CPU memory limitation per process.[/QUOTE]
Thanks, I’m just getting back into OGL after 10+ years (remember the Super Bible with the planes on it?).
Actually what I was wondering was about a possible limitation in OpenGL on 2-4 gb of vram. We’re at the point with SLI/Crossfire where you are getting up there. OpenGL is supposed to be scalable working with mainframes and what not, but I’m not sure if this is included locally.
Sorry, I typed a wrong word, it should be “voxel” for 3D data set.