tag:blogger.com,1999:blog-5417613544042855153.post3965184539304603441..comments2023-10-08T05:34:44.995-07:00Comments on CUDA Musing: Calling CUDA Fortran kernels from MATLABMassimilianohttp://www.blogger.com/profile/06026735414532627847noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-5417613544042855153.post-91700812581963133272017-02-16T14:35:09.194-08:002017-02-16T14:35:09.194-08:00Hi, since TF v1.0 released yesterday, I'm look...Hi, since TF v1.0 released yesterday, I'm looking forward to the new tutorial. <br />Thanks for this, You're helping a lot of people!Anonymoushttps://www.blogger.com/profile/18344692254012225551noreply@blogger.comtag:blogger.com,1999:blog-5417613544042855153.post-17974173298601135712013-09-14T06:58:40.661-07:002013-09-14T06:58:40.661-07:00Hi. That might have some effect, but the performa...Hi. That might have some effect, but the performance difference (~2x) doesn't seem to change for codes that call the kernel even hundreds of thousands of times over the course of execution. I've always assumed that there is some extra amount of processing that is done to the code to incorporate it into a *.mexa64 as opposed to a *.ptx (and, as you say, the corresponding SASS assembler...i didn't know that; thank you for the insight...) but I don't pretend to know. Whatever the case, for the same kernel with the same thread grid configuration, I consistently see the ~2x performance hit which is enough for me to go through the extra effort to use the MEX interface once the kernel is thoroughly tested. Stuhttps://www.blogger.com/profile/11332999137565791777noreply@blogger.comtag:blogger.com,1999:blog-5417613544042855153.post-58115873053886559492013-09-13T22:58:21.252-07:002013-09-13T22:58:21.252-07:00I think Matlab needs to JIT the PTX file to genera...I think Matlab needs to JIT the PTX file to generate SASS assembler (the native code that is going to execute on the GPU).<br />Have you tried to call a warm-up kernel? I have noticed that the following invocations are much faster.<br />The computer I was using had an old GPU, but I just replaced it with a faster one and will do more performance testing.<br /><br />The PGI toolchain and MEX don't play nice together, if I get something to work I will post my findings.Massimilianohttps://www.blogger.com/profile/06026735414532627847noreply@blogger.comtag:blogger.com,1999:blog-5417613544042855153.post-36110639746819096642013-09-13T11:57:17.283-07:002013-09-13T11:57:17.283-07:00Excellent.
Can you also extract a pointer (to dat...Excellent.<br /><br />Can you also extract a pointer (to data resident on the device) from a mxGPUArray object in a MEX file and pass to a function written in CUDA Fortran? Do the MEX and pgf90 toolchains work nicely together for CUDA codes?<br /><br />The only reason I ask is that, while I agree that the cudaKernel interface as you describe is a lot more convenient than MEX files, I have noticed a significant performance penalty on the cudaKernel (with the *.ptx file) vs calling the same kernel on GPU data in a MEX file. (...and, of course, the resulting *.mexa64).<br /><br />a. I don't really know why the performance is better with the *.mexa64...I just know that it is.<br /><br />b. I wouldn't be surprised if it's just that I'm doing something wrong with the *.ptx file and the cudaKernel interface. <br /><br />c. Do you notice any performance change in the *.ptx version compared to other codes that incorporate the same CUDA Fortran kernel?<br /><br />Thanks again. Nice blog.Stuhttps://www.blogger.com/profile/11332999137565791777noreply@blogger.com