|
|
utilize both video cards on MBP? I have a MBP with NVIDIA GeForce 9400M and NVIDIA GeForce 9600M GT Can anyone please help me to utilize both cards; as in when I connect an external display such as LED cinema or video projector, I would have thought the NVIDIA GeForce 9400M would take care of the MBP LCD and the NVIDIA GeForce 9600M GT would run the external display!? When I check the system Profiler - it seems that the NVIDIA GeForce 9400M is running both displays!?.... Sorry I know this isn't kineme related - but couldn't find any help/answers on apple support!?
|
Unless such a dedicated switching with turbo graphics option application can be built, then currently, for the purpose you are speaking off, AFAIK, the answer is a resounding and IMHO, underwhelming no.
Yes there is OpenCL that does allow for switching between the two GPUs and the CPU, otherwise my understanding from other MBP users is that they have to switch between the two, the on board 9400M being capable of longer term use before recharge than the dedicated GPU, used in combo I wouldn't be at all surprised to find that the battery stats would take a real hammering.
It is done on other vendors 9400 M and 8600M GT dual builds and works very well indeed.
TurboGraphics [dual GPU or dual SLI] - maybe round the corner, for all I know.
thanks for the response Cybero! - so when is the second card actually used?... do you mean if the on board 9400M gets 'tired?' then the second kicks in? - Do I understand you correctly in that one can switch between the two? - if so how? thx
I think the way it works is simply if you have an app that uses the video card (i.e. openGL, CI etc.) then it will use the GPU. If not, it'll use the intel chip.
No idea how plugging two displays in affects it though. There is a tool somewhere that tells you which GPU is doing what, possibly which apps are forcing it to use the GPU too. Can't remember what it's called, I'm sure a google search will find it :)
riviera, believe it or not, no explicit interface exists as such on the MacBookPro edition you speak off, [which I believe I'm correct in saying does not include an Intel on board chipset at all].
If I'm correct in that general assumption borne from my understanding of what you've posted then you need to open up System Preferences, select Energy Saver [who knew .. ;-)] and set to Higher performance for the 9600GT GPU [not 8600 - doh] and Better battery life for the 9400GM GPU.
Running both concurrently shouldn't prove to be absolutely impossible I'd have thought , unless that facility is permanently blocked at either the board level or by having to literally recompile an otherwise resistant framework [assuming the requisite source code for that were available].
Darn , it gets worse, just found this ..Switching OS X MBP GPUs looks like you need to log out and in to switch, so no switching on the fly as such..
Brilliant •~, isn't it :-|
Footnote having trumpeted forth the facility on other distros, I've got to admit there not all like Optimus capable of seamless switching, so you're not really lacking much of what you can generally get anywhere else by any other means.
Just did another quick search and it looks rather as if nVidia is giving up on Optimus.... watch this space ...
I'm not sure if the 9600GT GPU comes with a dual display output; even then it would either be dual on a single card or a dual display output junctioned and switchable between the two GPUs connected.
Higher quality / lower battery life, lower quality / higher battery life.
I think you are speaking off a later edition MBP than the one posted up about, or possibly one earlier than that posted, psonice.
gfxCardStatus by Cody Krieger lets you override the automatic switching and choose which card. This is very useful for battery life since flash always likes to turn on the power hungry one, even for things that don't need it like ads and the gmail attachment uploader. It also tells you which running applications triggered the switch to the NVIDIA card.
Unfortunately it does not have any way to control which monitor is run by which card. On mine, forcing it to stick with the Intel card means that an external display just flat out doesn't work.
Just realized you were talking about an earlier MBP, in that case gfxCardStatus probably won't do anything for you.
see example below for mac book pro running both cards.
Yep, I'm thinking of the later ones with automatic switching. And the app was the one that dwskau mentioned.
ok disregard my other comments. ten crashes later and it is possible to run both cards at the same time. check attached example.
Just to clarify: are we concluding it's not possible to run both cards on the generation of MacBook Pro laptops that required logging out to switch GPU?
a|x
yeah seems to be possible. can you get the example i posted to run? don't change the image size. i tested on a mbp with 9400 and 9600 cards. im thinking when i tried this before either the calculation was to big to run on the 256 causing os x to switch cards and subsequently crashed because i was using the bigger card as well. i'm hoping thats no the case and i'm wrong as i explicitly told process x to run on the 9400 and not the 9600. os x does automatically switch between cards if your battery settings are set to 256 so be careful if your using both. or at least thats what i read on another forum. doesn't mean its true though. i have my system set to 9600 in energy saver settings now so the computer will not automatically switch if it needs to. really though who knows why CL crashes sometimes it just does.
That's rather cool. It does seem to work on my MBP, in fact!
Incidentally, you've used OpenCL more than me, maybe you can explain in words my puny earthling brain can understand, the different between Work Item Dimensions and Output Dimensions. Every time I use OpenCL I get really confused about this stuff.
a|x
they confuse the hell out of me as well. its easier to understand not using pictures where you do not need a separate x and y workgroups of different sizes.
so for a dae loader you would take your vertex count as your x workgroup size and for your output sizes they are the same.
for an image you would want to use both x and y work groups your x is width and y is height. your output size of a float4 color would be your width times your height.
so if your using just X work group then to index through your verts you would say verts[tid] where tid is your workgroup x size.
if you want to use an image to store as color for your verts you would use use both X and Y work groups but your index would be tid_y * get_global_size(0) + tid_x; you don't declare a global size.
so of you wanted to loop through the colors of your image you would do something like.
int tid_x = get_global_id(0), tid_y = get_global_id(1), size = get_global_size(0); indx = tid_y * size + tid_x;this will give you coords for the image.
this will read your image in.
next you want to assign your color to a float4 output.
now lets make another kernel that should be easier to understand and use the output colors.
first set your global worksize to the output size of your colors kernel using structure count or width times height should be the same.
now lets loop through the colors and do something. try and stay away from loops as normally saying colors[tid] is good enough. so you would assign color to temp float4 c = color[tid] this copies all your colors to a new variable. so you can say if(c.x > .5) do something; for the sake of looping through something you will need to assign your colors to an output first as inputs are constant. you can do this even if your not using the output for nothing more than to calculate.
now you have an array you can loop through. just in case your out sizes are incorrect make sure size doesn't exceed your global thread count. then you can loop.
if ( size != tid ) { for (int i = 0; i < size; i++) { if(color.x == .2) outColor[i] = 1; } } normally you want to stay away from looping but if you keep things small you will not have an issue. like i said just saying if color.x == .5 then color.x = 1 will replace .5 with 1 of the same pixel index. you would only want to loop if you want to assign that value to a different pixel at a different index. float4 is like a glsl vec4 but an array the size of your outputs so you have to think that vec4 is attached to each index.Thanks very much for the explanation dust. Where things seem to get more complicated is where you've got inputs of different sizes. For example, you might want to loop through the items in an array, but use a lookup table stored in an image connected to a second input. In this scenario, I'm unsure what settings to use. Also, there are settings for Local and Global sizes. I'm not sure what Local does..
a|x
Think of the global size like the "cap" of how big of something you can work on, while you can use local sizes to deal with chunks of data that evenly divide into the global size.
You can keep local size equal to global size... which is generally how I see most people use it in QC, but that isn't always most performant. Simpler to setup though, since there isn't anything to think about really. If you leave it automatic (specify nothing), I think that technically behind the scenes stuff might be getting broken up into local sizes, it's not necessarily assumed that local size=global size.
for local you don't declare the size output your sort of sharing it so leave it at 0. using local mem will let you do things a different sizes like george said. for instance the bodySize can be half the size of your index size. check out the n-body example for good use of local.
int index = get_global_id(0), tidx = get_local_id(0), size = get_local_size(0), tile = 0, i, j; float bodySize = 1200; float4 pos = oldPos[index], verlets = make_float4(0.0f, 0.0f, 0.0f, 0.0f), for(i = 0; i < bodySize; i+= size, tile++) { sharedPos[tidx] = oldPos[tile * size + tidx]; barrier(CLK_LOCAL_MEM_FENCE); for(j = 0; j < blockDimX; ) { verlets += sharedPos[j++]-pos/deltaTime*deltaTime; } barrier(CLK_LOCAL_MEM_FENCE); }OK, that sort of makes sense. What determines when you might manually set a particular local size though?
a|x
OK. So, fundamentally, what is Global and Local memory? I'm kinda assumed in the past that Local memory was on the CPU side, whereas Global data was stored on the GPU, but this could be complete rubbish...
a|x
My understanding is local is faster cache on the individual processing core (the GPU has many hundreds of these), global is slower vram. Fitting things into local memory will give you much faster throughput. Check the OpenCL developer videos on Apple.com, they go over this sort of optimization. Of course, i've done next to zero CL work, so take that with a grain of salt.
twitch Double post.
Global memory is the largest available memory resource on the system running the OpenCL kernel or program.
Local Memory is the GPU on chip memory.
Local memory available will likely be smaller than Global memory.
Ah.. OK. That makes sense, vade. Thanks for the info.
a|x
Hmm, OK. So Global memory can include RAM on the host CPU? Or are both Global and Local memory on the GPU, assuming the kernel is running on the graphics card?
a|x
Both GPU and CPU have OpenCL available Global memory [limited by their physical memory capacity] and local memory, local memory is also physically limited as a result of what was set as local memory when the chipset was designed.
Try running oclinfo from Insanely Mac.
That should give you a good read out. Sorry to be so vague earlier, a|x, however, this is a device dependent thing, the device being the system running the kernel.
Hopefully that's a little clearer.
{I think we were geeking past one another :-)]
This is the sort of output you should get, plus one further device, I believe. [oh lucky you]
Last login: Wed Feb 23 23:45:58 on ttys000 /Users/cybero/Desktop/oclinfo/oclinfo ; exit; cpc4-seac20-2-0-cust448:~ cybero$ /Users/cybero/Desktop/oclinfo/oclinfo ; exit; 1 OpenCL platform found! [Platform 0] Name: Apple Vendor: Apple Version: OpenCL 1.0 (Aug 22 2010 18:08:16) Profile: FULL_PROFILE [OpenCL-only Context] 2 OpenCL devices found! [Device 0] Name: GeForce 9400 Vendor: NVIDIA Type: GPU Device Version: OpenCL 1.0 Driver Version: CLH 1.0 Compute Units: 2 Work Group Size: 512 Clock: 1150 MHz Global Memory: 256 MB Local Memory: 16 KB Cache Size: 0 KB Cache Line Size: 0 Bytes Available: Yes Double-Precision: No Extensions: cl_khr_byte_addressable_store cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_APPLE_gl_sharing cl_APPLE_SetMemObjectDestructor cl_APPLE_ContextLoggingFunctions [Device 1] Name: Intel(R) Core(TM)2 Duo CPU E8135 @ 2.66GHz Vendor: Intel Type: CPU Device Version: OpenCL 1.0 Driver Version: 1.0 Compute Units: 2 Work Group Size: 1 Clock: 2660 MHz Global Memory (Total): 4096 MB Global Memory (Host): 3072 MB Global Memory (PCIe): 1024 MB Local Memory: 16 KB Cache Size: 6144 KB Cache Line Size: 64 Bytes Available: Yes Double-Precision: Yes Extensions: cl_khr_fp64 cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_APPLE_gl_sharing cl_APPLE_SetMemObjectDestructor cl_APPLE_ContextLoggingFunctions [shared OpenCL+OpenGL Context] 2 OpenCL devices found! [Device 0] Name: GeForce 9400 Vendor: NVIDIA Type: GPU Device Version: OpenCL 1.0 Driver Version: CLH 1.0 Compute Units: 2 Work Group Size: 512 Clock: 1150 MHz Global Memory: 256 MB Local Memory: 16 KB Cache Size: 0 KB Cache Line Size: 0 Bytes Available: Yes Double-Precision: No Extensions: cl_khr_byte_addressable_store cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_APPLE_gl_sharing cl_APPLE_SetMemObjectDestructor cl_APPLE_ContextLoggingFunctions [Device 1] Name: Intel(R) Core(TM)2 Duo CPU E8135 @ 2.66GHz Vendor: Intel Type: CPU Device Version: OpenCL 1.0 Driver Version: 1.0 Compute Units: 2 Work Group Size: 1 Clock: 2660 MHz Global Memory (Total): 4096 MB Global Memory (Host): 3072 MB Global Memory (PCIe): 1024 MB Local Memory: 16 KB Cache Size: 6144 KB Cache Line Size: 64 Bytes Available: Yes Double-Precision: Yes Extensions: cl_khr_fp64 cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_APPLE_gl_sharing cl_APPLE_SetMemObjectDestructor cl_APPLE_ContextLoggingFunctions logout [Process completed]now to watch that bad breaking bad •~
copencl-performance-surprise-on-macbook-pro relates to the Energy Saver tip posted earlier .
i changed my boot preferences to alway boot in high performance mode a while back. my computer seems to remember my settings now but i had to manually do this at one point.