What collateral/documentation do you want to see?

[BelindaLiviero]

Do you have questions that you are not finding the answers for in our documentation?  Need more training, source code examples, on what specifically?   Help us understand what's missing so that we can make sure we develop documentation you care about (what is important, and what is nice to have)!   Thank you

[Vladimir_Dergachev]

It would be nice in addition to default installation to have example of very minimal root filesystem which has most utilities stored on NFS share, as well as tarball with more utilities.

For example, in addition to "base", "common" and "micX" in /opt/intel/mic/filesystem it would be nice to have "nfs" and have it populated with everything ever compiled for mic, such as (for example) gdb that currently resides elsewhere. It would be nice to have a more recent edition of perf.

Also, I could not find swapon/swapoff for Xeon Phi, it would be very nice to have these available.

thank you

Vladimir Dergachev

[Jeff_D_1]

I would really like to see documentation and/or instructions on how to setup Boinc to run on Phi. If I had that I would buy one. I know several others who are interested but we can't seem to find any info on how to make it work or even it if works with Boinc or even Folding@home.

Boinc is used to crunch for disease research such as cancer as well as dozens of other projects. The potential for Phi is enormous since most projects are still CPU bound.

[Nils_M_1]

We would be pleased if more information on a variety of topics were availiable:

• The details of the SBOX control registers. In the Appendix of the System Software Developers Guide (May 2013) hundreds of registers are listed, but their content is not revealed. Reading values such as, e.g., temperatures is possible but meaningless since one cannot decode the values.
• The details of the DMA controller, and some examples of how to program it. A variety of applications would gain from direct access to the DMA engine on the MIC.
• Efficient ways for thread synchronization.

[javiroman]

Hi!

A better MPSS source code organization would be wellcome, or even a MPSS source organization HOWTO document.

Many thanks.

[GHui]

I want to get doucumet about how to get CPU_CLK_UNHALTED and INSTRUCTIONS_EXECUTED on MIC. THanks.

[Pinak_P_]

Hi, I would like to find the documention regarding the physical numbering of cores on the INTEL MIC. I mean, which physical core is adjacent to which one on the chip.

[Rainer_K_]

Desperately looking for demo code.

My job as a test engineer required me to do some playing around with the Intel Xeon Phi cards (3120A and 5110P) on our company's recent workstations. My focus is definitely not Parallel Computing so I was there and realizing that "a fool with a tool is still a fool". :-)

When I had to see about CUDA support for the nVidia GPUs there were nice demos to download so that even without being in the parallel computing stuff you could easily push the load on the card to 100% and be impressed at the GFlops that the tools are reporting.

On Intel Xeon Phi there was nothing like that. The nicest thing I found was the monitoring program that at least showed how the temperature on the 5110P was rising because cooling equipment was too poor in the first tests. Meanwhile I found the code samples on http://lotsofcores.com/article/code-samples-now-available so with some of the sample programs there I can put 100% load on the card and do my tests. But I'm really missing a sort of "eye candy" that easily shows the power of the coprocessor card.

Regards

Rainer

[Frances_R_Intel]

@Pinak P. I don't believe there is any documentation on which core is where on the chip nor is there likely to be. But is your concern more one of information on how your program is distributed around the ring interconnect?

@Rainer K. There are sample programs for the coprocessor provided with the compilers ( /opt/intel/composerxe/Samples/en_US/C++/mic_samples, /opt/intel/composerxe/Samples/en_US/Fortran/mic_samples) and performance workloads provided with the MPSS (not installed by default but you can find the directions for installing them in the readme-en.txt file that comes with the MPSS.) Are these the sort of things you were looking for? If so, then maybe what we need to do is make them easier to find. If not, can you let us know what sort of things we should be looking at adding?

[Pinak_P_]

@Frances What do you mean by "But is your concern more one of information on how your program is distributed around the ring interconnect?" ...... I did not exactly follow that. I am working on MPI programs and am looking at some latencies when cache-lines are transfered from one core's L2 to another. I was looking for some information like this one has for the Cell processor: http://www.ibm.com/developerworks/power/library/pa-cellperf/ (figure 4) ..... I would also like to know the maximum bandwidth the 'ring interconnect' is capable of.

[Tim_D_1]

@GHui 

You can use PAPI to get these. At my github theres a wrapper for papi that can be easily used in offload or native mode to record CPU_CLK_UNHALTED and INSTRUCTIONS_EXECUTED, check the readme and example here for more info:

https://github.com/TimDykes/IntelMIC/tree/master/papi_wrapper

GHui wrote:

I want to get doucumet about how to get CPU_CLK_UNHALTED and INSTRUCTIONS_EXECUTED on MIC. THanks.

[j0e]

Here are a couple of points I had issues with while getting my Phi cards configures, etc.  I have not read all of the available documentation, so some of these may already be explained, but they were not in the readme file that came with MPSS.  Also, my main problems where associated with linux, but others may have the same issues so I think it's worth documenting.

1. If you want to use all the Phi cards on a given piece of hardware, then you need to setup the appropriate bridge (at least if using MPI).  Frances was very helpful pointing me to the relevant documentation, but it would have been nice if there was a better pointer to that documentation in the readme.txt file that is supplied in the MPSS package.
2. I still have issues getting processor and coprocessors communicating after some major change.  This is a basic linux problem for me, as I don't use linux that often.  While it was pointed out (somewhere) that you need to be able to ssh from cpu to phi, phi to cpu, and phi to phi, it still seems to plague me when I need to set it up (our lab just change all IPs to private network, so I just had to do it again).  Even after public keys are copied around, getting the known_hosts file properly setup also causes issues (i currently just ssh from each node to all others so the file gets setup correctly at each location).  There must be a better way of setting this up, but this is where my lack of linux slows me down.
3. There are a few posting about what intel libraries need to be copied over to the phi cards inorder for MPI programs to run.  These postings are useful (but not complete, as I had to add a few libraries after getting runtime errors), but they should be better documented.  I sure setting up NFS would be a better way to go, I'm still working on that.
4. Perhaps it's just me, but documentation, postings, etc seem scattered, so you have to hunt, and sometimes you don't know exactly what you're hunting for.  It would be nice if in the MPSS readme file if there were better pointers (that may be too difficult though).
5. Finally, it would be nice if you could directly search this forum, like you can on other Intel forums.  Limiting a google search to software.intel.com turns up too much unrelated info.    Many peoples questions are already answered, but they are nearly impossible to find as the forum is currently setup.

I will add that this forum is great!  There are many people here that are very helpful and respond amazingly quickly, so thanks (i did get everything working...at least so far :)

cheers,

-joe

[BelindaLiviero]

Joe, we really appreciate your feedback and we will continue to try to improve the organization of it all.  

What I _can_ tell you is that item (5) (being able to search this forum alone) is now implemented -- this was a recent change, and perhaps could be made more visible -- if you go to http://software.intel.com/en-us/forums/intel-many-integrated-core and look at the bottom of the initial 'Announcements" section there is a "Search within this Forum" link.   I will talk to our web designers to see if we can make that a bit more obvious!

[high_end_c_]

Hi - I agree that the Intel fora are great. I've used them a lot and am also building up tips at http://highendcompute.co.uk/XPhi so welcome ideas. Yours @highendcompute

[Sally_H_]

Hi Belinda, I would like to know more about using external NFS servers -- the documentation seems to imply that you can only NFS mount to the MICs something that is shared from the local server.  Is that only for an internal bridged network?  For example, if I setup an external bridged network, does the MPSS (v3.1 on Linux) software support NFS mounting something external to the server?  I will be testing this, but I have to get IPs allocated in order to do so and that takes some time. 

Thanks, Sally.

[Frances_R_Intel]

Sally,

If you set up an external bridge, then you should be able to NFS mount from any reachable server. I will make a note that the documentation on this needs work.

Frances 

[Sally_H_]

Frances,

Thanks - that's good news.  I have another question then :-) 

For the external bridged network, how do I specify a particular IP address for each MIC?  The commands in the doc (p.100) indicate that you have to use consecutive IPs (ie. last octet is bridge, mic0=bridge+1, mic1=bridge+2 - in the example, node 0 is 2, 3 and 4).  Is that the case, or can you specify completely different IPs? 

Thanks, Sally

[Frances_R_Intel]

Sally,

As long as everyone is in the same subnet, no, I believe they don't need to be consecutive. If you use a single "micctrl --network" to set all the cards at once, then they will be assigned consecutive addresses by default. But you should be able to set them to individual values by using a different "micctrl --network" command for each card. If that doesn't work for you, let me know. It might be best to start a new forum issue at that point though, so that it will be easier for us to track the issue.

Frances

[James_Y_1]

Belinda, I'd like to see more info on best practices for OpenCL on MIC.  As an example I'm considering a Phi coproc for an OpenCL app, and I'm guessing that local memory caching (like one does for tiled GEMM to minimize memory bandwidth  on GPUs). But GPUs actually have dedicated hardware memory per compute unit, whereas for MIC I'm guessing there is no such thing, and using __local buffers woudn't help, but probably actually hurt.

[Arik_N_Intel]

James,

Thanks for your feedback.

I assume that the following paper answer part of your request: http://software.intel.com/en-us/articles/opencl-design-and-programming-guide-for-the-intel-xeon-phi-coprocessor

The paper can be accessed through the "training" tab in the main OpenCL XE page: www.intel.com/software/opencl-xe

Were you aware of that OpenCL XE training page? What should be improved with respect to OpenCL BKMs sharing? (content and format)

Arik

[James_Y_1]

Thanks Arik, that's what I was looking for.

[Harry_McG]

I noticed there is a Windows MPSS, does this mean if it is running on Windows 7 and a program such as Adobe Premier which has OpenCL support will be able to use the cores of the Intel Phi?

Will Windows 7 show the cores as extra cores in Windows as it would with XEON CPU's?