Not true! With few exceptions, x64 code runs significantly faster than 32-bit x86 code. Most (not all) of the speed-up comes from the x64 instruction set supporting twice as many hardware registers as the x86 instruction set, so fewer load/store operations to/from memory are required in optimized code.
But the vast majority of users with 64-bit Intel processors that (for whatever reason) have to run the 32-bit kernel will not be running kernel code most of the day. The vast majority of the time, they will be running 64-bit apps--when available--and the vast majority of the computation time will take place within the apps. For the vast majority of users it won't matter whether they run the 32-bit or 64-bit kernel. The principal benefit to having 64-bit hardware will come from running 64-bit apps.
Sorry, but it is true.
Yes, if you had old Windows code, written for old x86 cpus, then a re write of your 8 bit, 16 bit, 32 bit mangled code, written for the old chips will run faster. The main difference is the larger number of 64 bit registers over the smaller number of shorter registers.
But Apple never had programs with that old code written for the old chips. Yonah was the oldest chip they ran on. The same thing for Apple's third party developers.
As a result, Apple could take advantage of the better support in Yonah, and then went directly to the 64 bit chips.
so we won't see the differences Windows users have seen with SOME software.
There is still the overhead of needing all 64 bit instruction memory resources, and the extra time to run those 64 bit instructions, and other problems associated with it.
I thought you didn't like making those kinds of predictions?
I knew someone wouldn't read what I said carefully, and would say that.
I made no prediction there.
What I did say is that there is no technical reason why Apple couldn't support 32 bit for one more upgrade beyond 10.6. I gave reasons why it was to difficult to do so before, as he was using examples from the past to support his contention.
Whether they will or won't isn't something I'm predicting.
I'm a geek, so I'm fascinated by all of these little intricacies, but ultimately I just want the OS do what I want/need with minimal annoyances, stability, and intuitive, classy GUI.
If OS X 10.6 does that, I'll be a happy camper - 64 bit or not.
You can?t. That is the best we have, but at this point in the game to think that all Macs with 64-bit CPUs and 64-bit chipsets will have a 64-bit EFI and be capable of loading a 64-bit kernel is unlikely considering that we are at the cusp of going Golden Master and there has been absolutely no developer testing of the 64-bit kernel for their most common machine hardware. Maybe they are having some problems and will include it later, this is Apple we?re talking about so we are foolish to expect them to fully disclose their future plans to us as it?s not in their nature. WE know what we know and we can infer some basic things. If your MBP is on that list then you are golden, if not, then you are likely SoL for the time being.
It just seems as though this is mostly driver issues. If they will run it on the Xserve with its reliance on reliability, then it's ready for primetime.
MS had to write many drivers themselves for 64 Vista because so many third parties either weren't going to be ready, or weren't bothering. They still had massive problems for at least a year after release. Some of that was due to the signing, but much of it was not.
It's possible that Apple is having the same problems with drivers, and doesn't want the resultant problems. Xserves wouldn't be expected to interact with so many third party peripherals, so would be good to go.
The list of K64 "Capable" systems is incomplete. For one at least, "MacPro4,1" is the Nehalem generation of Mac Pro, which is listed, but the unlisted Harpertown generation ("MacPro3,1") also has a 64-bit EFI and will be able to run the 64-bit kernel.
Just having the 64-bit CPU, chipset and EFI doesn’t mean you will have access to the 64-bit kernel. I have all those on a 13” MBP and yet I can’t load the 64-bit kernel despite System Profiler stating quite clearly
BSDKernel:
Versiont10.0.0
Last Modifiedt7/24/09 8:31 PM
Get Info StringtBSD Kernel Pseudoextension, Apple Computer Inc, 10.0.0
Being technically possible doesn’t mean that Apple is going to greenlight it.
Quote:
Originally Posted by melgross
It just seems as though this is mostly driver issues. If they will run it on the Xserve with its reliance on reliability, then it's ready for primetime.
MS had to write many drivers themselves for 64 Vista because so many third parties either weren't going to be ready, or weren't bothering. They still had massive problems for at least a year after release. Some of that was due to the signing, but much of it was not.
It's possible that Apple is having the same problems with drivers, and doesn't want the resultant problems. Xserves wouldn't be expected to interact with so many third party peripherals, so would be good to go.
I’m sure it is. As you say, very few peripherals are plugged into servers so it’s easy to be assured that Xserves would have the 64-bit drivers required. Macs are a different story and I understand why defaulting to a 32-bit kernel is the smart move, what I don’t get is the inability for certain Macs that appear to match all the necessary criteria to not even be capable of loading the 64-bit kernel.
Hello Guys, I think this debate that a 64bit cpu with a 32bit EFI will not run a 64bit kernel is useless because I am running both Mac OS X Snow Leopard 10A421a and Ubuntu 9.04 64 bit on my mid 2007 core 2 duo mac mini. Though my mac has 32 bit EFI it happily loaded the 64 bit kernel of Ubuntu with all the drivers etc. Thus I am quite confident that I am running Snow Leopard in pure 64 bit mode.
Just having the 64-bit CPU, chipset and EFI doesn?t mean you will have access to the 64-bit kernel. I have all those on a 13? MBP and yet I can?t load the 64-bit kernel despite System Profiler stating quite clearly
BSDKernel:
Versiont10.0.0
Last Modifiedt7/24/09 8:31 PM
Get Info StringtBSD Kernel Pseudoextension, Apple Computer Inc, 10.0.0
Being technically possible doesn?t mean that Apple is going to greenlight it.
I?m sure it is. As you say, very few peripherals are plugged into servers so it?s easy to be assured that Xserves would have the 64-bit drivers required. Macs are a different story and I understand why defaulting to a 32-bit kernel is the smart move, what I don?t get is the inability for certain Macs that appear to match all the necessary criteria to not even be capable of loading the 64-bit kernel.
Well, I question whether the information as to the architecture being x86 64 bit follows through to the 965 chipset, or the 3000, or the 3100. It could just be referring to the cpu. In that case, it might not be possible.
Hello Guys, I think this debate that a 64bit cpu with a 32bit EFI will not run a 64bit kernel is useless because I am running both Mac OS X Snow Leopard 10A421a and Ubuntu 9.04 64 bit on my mid 2007 core 2 duo mac mini. Though my mac has 32 bit EFI it happily loaded the 64 bit kernel of Ubuntu with all the drivers etc. Thus I am quite confident that I am running Snow Leopard in pure 64 bit mode.
That is a fallacious conclusion. As we’ve been discussing, what Apple is allowing may not be the upper limits of what is technically possible.
If your /Library/Preferences/SystemConfiguration/com.apple.Boot.plist has a null value for Kernel Flag then you are running a 32-bit kernel. You can also click on Software in System Profiler to see if 64-bit Kernel and Extensions: says Yes or No.
Well, I question whether the information as to the architecture being x86 64 bit follows through to the 965 chipset, or the 3000, or the 3100. It could just be referring to the cpu. In that case, it might not be possible.
That is a fallacious conclusion. As we’ve been discussing, what Apple is allowing may not be the upper limits of what is technically possible.
If your /Library/Preferences/SystemConfiguration/com.apple.Boot.plist has a null value for Kernel Flag then you are running a 32-bit kernel. You can also click on Software in System Profiler to see if 64-bit Kernel and Extensions: says Yes or No.
Hello Dear, This is what is mentioned under my BSD Kernel in System profiler:
BSDKernel:
Versiont10.0.0
Last Modifiedt7/27/09 4:30 PM
Get Info StringtBSD Kernel Pseudoextension, Apple Computer Inc, 10.0.0
Yeah, you have a 64-bit CPU from Intel. Great! That doesn’t mean you are running a 64-bit kernel at the moment or that you are even able to under Snow Leopard. Your Kernel Flag value is empty and you didn’t state the result for 64-bit Kernel and Extensions:. As you can see from my previous posting I have the same values for BSDKernel yet I have a No for 64-bit Kernel.
By the way, I see from all your posts here that you're trolling.
Why bother? Does it make you feel good to give only partly correct information, while disregarding the rest?
Wow, and how do you read that report? Please do tell, because that particular report has been discussed to death by now in technical circles, and I have followed it very closely.
Apple's core animation still runs slower on nVidia chips that it does on lower end ATI cards. It has gotten slightly better in 10.5.5, but it's still slower.
3D performance of nVidia (using Open GL) is better though, but games mostly use that (not apple pro apps). And who games on a Mac in OS X anyway.
Wow, and how do you read that report? Please do tell, because that particular report has been discussed to death by now in technical circles, and I have followed it very closely.
Apple's core animation still runs slower on nVidia chips that it does on lower end ATI cards. It has gotten slightly better in 10.5.5, but it's still slower.
3D performance of nVidia (using Open GL) is better though, but games mostly use that (not apple pro apps). And who games on a Mac in OS X anyway.
Because your conclusions are a lot of BS to begin with.
According to you, the report tells you that, even it not in those words:
Quote:
This means that someone at Apple doesn't know how to write optimized drivers for nVidia cards. But no big deal. No one uses Mac for graphics any more anyway. Since all Adobe apps (besides being 64 bit on Windows already) are optimized to smithereens for Windows platform, that there is a significant measurable performance gain running those same apps on Windows than Mac. Hence, anyone just starting computer purchase should consider these things.
Now, show me exactly where in that report that anything you said here invalidated my statement. Where in that report did they say that Apple doesn't know how to write drivers?
Where did they say anything you've said other than the card did 3D games well?
So again, I repeat that you don't understand the report, or are trolling with your far out statements.
According to Intel's specs, you can only get 4MB of Ram for the 965 Express chipset, even though it uses 64 bit DIMMS.
It has a 32 bit downstream address in the DMI.
Chipset caches are 64 bit.
The chipset addresses 64 GB of addressable memory space. — This answers some questions.
The processors have a 36 bit address interface.
It's not clear to me that any of the Santa Rosa platforms are capable of handling a 64 bit OS at the kernel level.
True for Windows or Mac.
Can someone else, who actually KNOWS (rather than assuming they know) explain this further?
I don't think any current processor or chipset actually has a physical 64-bit address interface since there is no reason to fully support 16 exabytes of physical memory at this time. I believe the meaning of a 36-bit address interface is that the chipset can support up to 64GB of RAM or in this case, since RAM support is limited to 4GB, the 4GB - 64GB region is used for device addresses. I believe the Napa platform only had a 32-bit address interface so device addresses were in the 3GB - 4GB region which is why the first-gen Core 2 Duo Macs only support 3GB of RAM. Being limited to a 32-bit or 36-bit address interface, should still mean you can get the full 16 exabytes worth of virtual memory.
Regardless, both Napa and Santa Rosa can still run a 64-bit OS, even if they can't support greater than 4GB of RAM. Afterall, more RAM isn't the only feature of a 64-bit OS. For example, the above link is a GMA 950 driver for 64-bit Windows XP. There are similar 64-bit drivers available for 64-bit Vista and for the GMA X3100. If the Napa and Santa Rosa platforms can't support a 64-bit kernel, then why bother writing 64-bit drivers which would be useless in a 32-bit kernel? Lack of 64-bit kernel support in Snow Leopard for all Core 2 Duo Macs is not a hardware limitation, it's a matter of Apple writing and supporting 64-bit drivers and EFI firmware.
I don't think any current processor or chipset actually has a physical 64-bit address interface since there is no reason to fully support 16 exabytes of physical memory at this time. I believe the meaning of a 36-bit address interface is that the chipset can support up to 64GB of RAM or in this case, since RAM support is limited to 4GB, the 4GB - 64GB region is used for device addresses. I believe the Napa platform only had a 32-bit address interface so device addresses were in the 3GB - 4GB region which is why the first-gen Core 2 Duo Macs only support 3GB of RAM. Being limited to a 32-bit or 36-bit address interface, should still mean you can get the full 16 exabytes worth of virtual memory.
Regardless, both Napa and Santa Rosa can still run a 64-bit OS, even if they can't support greater than 4GB of RAM. Afterall, more RAM isn't the only feature of a 64-bit OS. For example, the above link is a GMA 950 driver for 64-bit Windows XP. There are similar 64-bit drivers available for 64-bit Vista and for the GMA X3100. If the Napa and Santa Rosa platforms can't support a 64-bit kernel, then why bother writing 64-bit drivers which would be useless in a 32-bit kernel? Lack of 64-bit kernel support in Snow Leopard for all Core 2 Duo Macs is not a hardware limitation, it's a matter of Apple writing and supporting 64-bit drivers and EFI firmware.
Then we're back to what I was saying about drivers.
What I'd like to know is what level of OpenGL support exists. Leopard was OpenGL 2.1. Presumably Snow Leopard will be at least OpenGL 3.0 since that introduced interoperability with OpenCL. Hopefully, OpenGL 3.2 support comes quickly since one of it's key features is that it's easier to port DirectX applications to OpenGL which can only be a good thing.
Using the app Libertyforall suggested there is complete support for OpenGL 1.1-1.5 and 2.0-2.1. There is no test available for OpenGL 3.0 or 3.1, but under the OpenGL list for my machine it shows that I have support for 16 out of 25 (64%) features of 3.0 and 1 out of 7 (14%) features of 3.1.
Using the app Libertyforall suggested there is complete support for OpenGL 1.1-1.5 and 2.0-2.1. There is no test available for OpenGL 3.0 or 3.1, but under the OpenGL list for my machine it shows that I have support for 16 out of 25 (64%) features of 3.0 and 1 out of 7 (14%) features of 3.1.
Here is a partial report…
Renderer: NVIDIA GeForce 9400M OpenGL
Engine Vendor: NVIDIA Corporation
Memory: 256 MB
Version: 2.1 NVIDIA-1.6.0
…
Core features
v1.1 (100 % - 7/7)
v1.2 (100 % - 8/8)
v1.3 (100 % - 9/9)
v1.4 (100 % - 15/15)
v1.5 (100 % - 3/3)
v2.0 (100 % - 10/10)
v2.1 (100 % - 3/3)
v3.0 (64 % - 16/25)
v3.1 (14 % - 1/7)
That's disappointing. That means that OpenGL support in Snow Leopard is really no better than Leopard. Leopard already had full OpenGL 2.1 support for all discrete GPUs in Intel Macs and partial OpenGL 3.0 support. nVidia has already released drivers for the 8000 series and up including the 9400M that has full support for OpenGL 3.1 in Windows and Linux. If I'm not mistaken, OpenGL 3.0 is important because it makes it easier to share data sets with OpenCL on a GPU so they can work nicely together. I'd imagine it'd be valuable for say fluid modeling applications where you want to crunch the data and visualize the flow (really OpenCL's bread and butter for the professional community) or for games with physics and graphics. It's interesting that Apple is pushing so hard for one but neglects the other.
Comments
Not true! With few exceptions, x64 code runs significantly faster than 32-bit x86 code. Most (not all) of the speed-up comes from the x64 instruction set supporting twice as many hardware registers as the x86 instruction set, so fewer load/store operations to/from memory are required in optimized code.
But the vast majority of users with 64-bit Intel processors that (for whatever reason) have to run the 32-bit kernel will not be running kernel code most of the day. The vast majority of the time, they will be running 64-bit apps--when available--and the vast majority of the computation time will take place within the apps. For the vast majority of users it won't matter whether they run the 32-bit or 64-bit kernel. The principal benefit to having 64-bit hardware will come from running 64-bit apps.
Sorry, but it is true.
Yes, if you had old Windows code, written for old x86 cpus, then a re write of your 8 bit, 16 bit, 32 bit mangled code, written for the old chips will run faster. The main difference is the larger number of 64 bit registers over the smaller number of shorter registers.
But Apple never had programs with that old code written for the old chips. Yonah was the oldest chip they ran on. The same thing for Apple's third party developers.
As a result, Apple could take advantage of the better support in Yonah, and then went directly to the 64 bit chips.
so we won't see the differences Windows users have seen with SOME software.
There is still the overhead of needing all 64 bit instruction memory resources, and the extra time to run those 64 bit instructions, and other problems associated with it.
The result can very well be a wash.
I thought you didn't like making those kinds of predictions?
I knew someone wouldn't read what I said carefully, and would say that.
I made no prediction there.
What I did say is that there is no technical reason why Apple couldn't support 32 bit for one more upgrade beyond 10.6. I gave reasons why it was to difficult to do so before, as he was using examples from the past to support his contention.
Whether they will or won't isn't something I'm predicting.
If OS X 10.6 does that, I'll be a happy camper - 64 bit or not.
You can?t. That is the best we have, but at this point in the game to think that all Macs with 64-bit CPUs and 64-bit chipsets will have a 64-bit EFI and be capable of loading a 64-bit kernel is unlikely considering that we are at the cusp of going Golden Master and there has been absolutely no developer testing of the 64-bit kernel for their most common machine hardware. Maybe they are having some problems and will include it later, this is Apple we?re talking about so we are foolish to expect them to fully disclose their future plans to us as it?s not in their nature. WE know what we know and we can infer some basic things. If your MBP is on that list then you are golden, if not, then you are likely SoL for the time being.
It just seems as though this is mostly driver issues. If they will run it on the Xserve with its reliance on reliability, then it's ready for primetime.
MS had to write many drivers themselves for 64 Vista because so many third parties either weren't going to be ready, or weren't bothering. They still had massive problems for at least a year after release. Some of that was due to the signing, but much of it was not.
It's possible that Apple is having the same problems with drivers, and doesn't want the resultant problems. Xserves wouldn't be expected to interact with so many third party peripherals, so would be good to go.
The list of K64 "Capable" systems is incomplete. For one at least, "MacPro4,1" is the Nehalem generation of Mac Pro, which is listed, but the unlisted Harpertown generation ("MacPro3,1") also has a 64-bit EFI and will be able to run the 64-bit kernel.
Just having the 64-bit CPU, chipset and EFI doesn’t mean you will have access to the 64-bit kernel. I have all those on a 13” MBP and yet I can’t load the 64-bit kernel despite System Profiler stating quite clearly
BSDKernel:
Version
Last Modified
Get Info String
Kind
Architectures
64-Bit (Intel)
Location
Kext Version
Load Address
Valid
Authentic
Dependencies
Being technically possible doesn’t mean that Apple is going to greenlight it.
It just seems as though this is mostly driver issues. If they will run it on the Xserve with its reliance on reliability, then it's ready for primetime.
MS had to write many drivers themselves for 64 Vista because so many third parties either weren't going to be ready, or weren't bothering. They still had massive problems for at least a year after release. Some of that was due to the signing, but much of it was not.
It's possible that Apple is having the same problems with drivers, and doesn't want the resultant problems. Xserves wouldn't be expected to interact with so many third party peripherals, so would be good to go.
I’m sure it is. As you say, very few peripherals are plugged into servers so it’s easy to be assured that Xserves would have the 64-bit drivers required. Macs are a different story and I understand why defaulting to a 32-bit kernel is the smart move, what I don’t get is the inability for certain Macs that appear to match all the necessary criteria to not even be capable of loading the 64-bit kernel.
Just having the 64-bit CPU, chipset and EFI doesn?t mean you will have access to the 64-bit kernel. I have all those on a 13? MBP and yet I can?t load the 64-bit kernel despite System Profiler stating quite clearly
BSDKernel:
Version
Last Modified
Get Info String
Kind
Architectures
64-Bit (Intel)
Location
Kext Version
Load Address
Valid
Authentic
Dependencies
Being technically possible doesn?t mean that Apple is going to greenlight it.
I?m sure it is. As you say, very few peripherals are plugged into servers so it?s easy to be assured that Xserves would have the 64-bit drivers required. Macs are a different story and I understand why defaulting to a 32-bit kernel is the smart move, what I don?t get is the inability for certain Macs that appear to match all the necessary criteria to not even be capable of loading the 64-bit kernel.
Well, I question whether the information as to the architecture being x86 64 bit follows through to the 965 chipset, or the 3000, or the 3100. It could just be referring to the cpu. In that case, it might not be possible.
Hello Guys, I think this debate that a 64bit cpu with a 32bit EFI will not run a 64bit kernel is useless because I am running both Mac OS X Snow Leopard 10A421a and Ubuntu 9.04 64 bit on my mid 2007 core 2 duo mac mini. Though my mac has 32 bit EFI it happily loaded the 64 bit kernel of Ubuntu with all the drivers etc. Thus I am quite confident that I am running Snow Leopard in pure 64 bit mode.
That is a fallacious conclusion. As we’ve been discussing, what Apple is allowing may not be the upper limits of what is technically possible.
If your /Library/Preferences/SystemConfiguration/com.apple.Boot.plist has a null value for Kernel Flag then you are running a 32-bit kernel. You can also click on Software in System Profiler to see if 64-bit Kernel and Extensions: says Yes or No.
Well, I question whether the information as to the architecture being x86 64 bit follows through to the 965 chipset, or the 3000, or the 3100. It could just be referring to the cpu. In that case, it might not be possible.
Good point.
That is a fallacious conclusion. As we’ve been discussing, what Apple is allowing may not be the upper limits of what is technically possible.
If your /Library/Preferences/SystemConfiguration/com.apple.Boot.plist has a null value for Kernel Flag then you are running a 32-bit kernel. You can also click on Software in System Profiler to see if 64-bit Kernel and Extensions: says Yes or No.
Hello Dear, This is what is mentioned under my BSD Kernel in System profiler:
BSDKernel:
Version
Last Modified
Get Info String
Kind
Architectures
64-Bit (Intel)
Location
Kext Version
Load Address
Valid
Authentic
Dependencies
And Also there is Yes after it there!
And this is what is see in com.Apple.Boot.plist file so you tell me am I running a 64 bit kernel or a 32 bit kernel?
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">;
<plist version="1.0">
<dict>
\t<key>Kernel</key>
\t<string>mach_kernel</string>
\t<key>Kernel Flags</key>
\t<string></string>
</dict>
</plist>
Hello Dear, This is what is mentioned under my BSD Kernel in System profiler:
BSDKernel:
Version
Last Modified
Get Info String
Kind
Architectures
64-Bit (Intel)
Location
Kext Version
Load Address
Valid
Authentic
Dependencies
And Also there is Yes after it there!
Yeah, you have a 64-bit CPU from Intel. Great! That doesn’t mean you are running a 64-bit kernel at the moment or that you are even able to under Snow Leopard. Your Kernel Flag value is empty and you didn’t state the result for 64-bit Kernel and Extensions:. As you can see from my previous posting I have the same values for BSDKernel yet I have a No for 64-bit Kernel.
Hello Dear, This is what is mentioned under my BSD Kernel in System profiler:
BSDKernel:
Version
Last Modified
Get Info String
Kind
Architectures
64-Bit (Intel)
Location
Kext Version
Load Address
Valid
Authentic
Dependencies
And Also there is Yes after it there!
And this is what is see in com.Apple.Boot.plist file so you tell me am I running a 64 bit kernel or a 32 bit kernel?
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">;
<plist version="1.0">
<dict>
\t<key>Kernel</key>
\t<string>mach_kernel</string>
\t<key>Kernel Flags</key>
\t<string></string>
</dict>
</plist>
The "yes" is referring to the Intel 64 bit architecture, not whether the kernel is 64 bit. You might notice that it offer several.
How are you running your printer without the required 64 bit driver?
Wow! You can't even read the report properly.
By the way, I see from all your posts here that you're trolling.
Why bother? Does it make you feel good to give only partly correct information, while disregarding the rest?
Wow, and how do you read that report? Please do tell, because that particular report has been discussed to death by now in technical circles, and I have followed it very closely.
Apple's core animation still runs slower on nVidia chips that it does on lower end ATI cards. It has gotten slightly better in 10.5.5, but it's still slower.
3D performance of nVidia (using Open GL) is better though, but games mostly use that (not apple pro apps). And who games on a Mac in OS X anyway.
Wow, and how do you read that report? Please do tell, because that particular report has been discussed to death by now in technical circles, and I have followed it very closely.
Apple's core animation still runs slower on nVidia chips that it does on lower end ATI cards. It has gotten slightly better in 10.5.5, but it's still slower.
3D performance of nVidia (using Open GL) is better though, but games mostly use that (not apple pro apps). And who games on a Mac in OS X anyway.
Because your conclusions are a lot of BS to begin with.
According to you, the report tells you that, even it not in those words:
This means that someone at Apple doesn't know how to write optimized drivers for nVidia cards. But no big deal. No one uses Mac for graphics any more anyway. Since all Adobe apps (besides being 64 bit on Windows already) are optimized to smithereens for Windows platform, that there is a significant measurable performance gain running those same apps on Windows than Mac. Hence, anyone just starting computer purchase should consider these things.
Now, show me exactly where in that report that anything you said here invalidated my statement. Where in that report did they say that Apple doesn't know how to write drivers?
Where did they say anything you've said other than the card did 3D games well?
So again, I repeat that you don't understand the report, or are trolling with your far out statements.
Curious... how do you know what you know?
From the interwebs.
According to Intel's specs, you can only get 4MB of Ram for the 965 Express chipset, even though it uses 64 bit DIMMS.
It has a 32 bit downstream address in the DMI.
Chipset caches are 64 bit.
The chipset addresses 64 GB of addressable memory space. — This answers some questions.
The processors have a 36 bit address interface.
It's not clear to me that any of the Santa Rosa platforms are capable of handling a 64 bit OS at the kernel level.
True for Windows or Mac.
Can someone else, who actually KNOWS (rather than assuming they know) explain this further?
I don't think any current processor or chipset actually has a physical 64-bit address interface since there is no reason to fully support 16 exabytes of physical memory at this time. I believe the meaning of a 36-bit address interface is that the chipset can support up to 64GB of RAM or in this case, since RAM support is limited to 4GB, the 4GB - 64GB region is used for device addresses. I believe the Napa platform only had a 32-bit address interface so device addresses were in the 3GB - 4GB region which is why the first-gen Core 2 Duo Macs only support 3GB of RAM. Being limited to a 32-bit or 36-bit address interface, should still mean you can get the full 16 exabytes worth of virtual memory.
http://downloadcenter.intel.com/filt...9&submit=Go%21
Regardless, both Napa and Santa Rosa can still run a 64-bit OS, even if they can't support greater than 4GB of RAM. Afterall, more RAM isn't the only feature of a 64-bit OS. For example, the above link is a GMA 950 driver for 64-bit Windows XP. There are similar 64-bit drivers available for 64-bit Vista and for the GMA X3100. If the Napa and Santa Rosa platforms can't support a 64-bit kernel, then why bother writing 64-bit drivers which would be useless in a 32-bit kernel? Lack of 64-bit kernel support in Snow Leopard for all Core 2 Duo Macs is not a hardware limitation, it's a matter of Apple writing and supporting 64-bit drivers and EFI firmware.
I don't think any current processor or chipset actually has a physical 64-bit address interface since there is no reason to fully support 16 exabytes of physical memory at this time. I believe the meaning of a 36-bit address interface is that the chipset can support up to 64GB of RAM or in this case, since RAM support is limited to 4GB, the 4GB - 64GB region is used for device addresses. I believe the Napa platform only had a 32-bit address interface so device addresses were in the 3GB - 4GB region which is why the first-gen Core 2 Duo Macs only support 3GB of RAM. Being limited to a 32-bit or 36-bit address interface, should still mean you can get the full 16 exabytes worth of virtual memory.
http://downloadcenter.intel.com/filt...9&submit=Go%21
Regardless, both Napa and Santa Rosa can still run a 64-bit OS, even if they can't support greater than 4GB of RAM. Afterall, more RAM isn't the only feature of a 64-bit OS. For example, the above link is a GMA 950 driver for 64-bit Windows XP. There are similar 64-bit drivers available for 64-bit Vista and for the GMA X3100. If the Napa and Santa Rosa platforms can't support a 64-bit kernel, then why bother writing 64-bit drivers which would be useless in a 32-bit kernel? Lack of 64-bit kernel support in Snow Leopard for all Core 2 Duo Macs is not a hardware limitation, it's a matter of Apple writing and supporting 64-bit drivers and EFI firmware.
Then we're back to what I was saying about drivers.
http://www.versiontracker.com/dyn/moreinfo/macosx/55098
Where can i find info on OpenGL versioning in OS X?
What I'd like to know is what level of OpenGL support exists. Leopard was OpenGL 2.1. Presumably Snow Leopard will be at least OpenGL 3.0 since that introduced interoperability with OpenCL. Hopefully, OpenGL 3.2 support comes quickly since one of it's key features is that it's easier to port DirectX applications to OpenGL which can only be a good thing.
Try OpenGL Extensions Viewer on your Macs:
http://www.versiontracker.com/dyn/moreinfo/macosx/55098
Using the app Libertyforall suggested there is complete support for OpenGL 1.1-1.5 and 2.0-2.1. There is no test available for OpenGL 3.0 or 3.1, but under the OpenGL list for my machine it shows that I have support for 16 out of 25 (64%) features of 3.0 and 1 out of 7 (14%) features of 3.1.
Here is a partial report…
Using the app Libertyforall suggested there is complete support for OpenGL 1.1-1.5 and 2.0-2.1. There is no test available for OpenGL 3.0 or 3.1, but under the OpenGL list for my machine it shows that I have support for 16 out of 25 (64%) features of 3.0 and 1 out of 7 (14%) features of 3.1.
Here is a partial report…
That's disappointing. That means that OpenGL support in Snow Leopard is really no better than Leopard. Leopard already had full OpenGL 2.1 support for all discrete GPUs in Intel Macs and partial OpenGL 3.0 support. nVidia has already released drivers for the 8000 series and up including the 9400M that has full support for OpenGL 3.1 in Windows and Linux. If I'm not mistaken, OpenGL 3.0 is important because it makes it easier to share data sets with OpenCL on a GPU so they can work nicely together. I'd imagine it'd be valuable for say fluid modeling applications where you want to crunch the data and visualize the flow (really OpenCL's bread and butter for the professional community) or for games with physics and graphics. It's interesting that Apple is pushing so hard for one but neglects the other.