[Intel-gfx] CUDA port for intel graphics
Hi, My name is Gregory Diamos. I am a PhD student at the Georgia Institute of Technology currently working on compiler backends for performing general purpose computation on GPU architectures. My research group at Georgia Tech (CASL) group develops and maintains the Ocelot backend compiler for CUDA (http://code.google.com/p/gpuocelot/). We are currently trying to perform architecture characterizations between different SIMD and multicore architectures and already have a detailed simulation and compilation infrastructure built around CUDA for NVIDIA GPUs, AMD GPUs, and Intel/AMD CPUs. We are particularly interested in evaluating the Intel GPU architecture due to the tight integration between the CPU and GPU in GMA3150 and in the roadmaps for Sandybridge (http://en.wikipedia.org/wiki/Sandy_Bridge_%28microarchitecture%29). After looking over the documentation in the programming guide, it seems like there is enough information of the ISA and buffer commands to do a backend for CUDA by generating an Intel binary for each CUDA program, and using buffer commands to setup memory, load the binary, and execute it. I would appreciate it if people who have worked with the open source linux driver could provide the following information so that I can gauge the feasibility and level of effort of this project. 1. Is there an interface for writing directly to the GPU ring buffer that is exposed by the driver? If not, would it be straightforward to add such an interface? 2. Are there any restrictions (security, DRM, etc) for loading/executing binaries on the media pipeline? 3. How modular is the driver? Is there an interface for user-level applications to issue hardware commands in a way that is isolated and time-shared with commands from the graphics driver? If not, would it be straightforward to modify the driver to disable the graphics components of the driver and retain only an interface for passing commands to the device? 4. How is memory sharing between the CPU and GPU handled? Is it possible to map memory from the CPU's address space into the GPU's address space? Sorry if this is already documented somewhere, I might have missed it. I appreciate any help that you can offer. Regards, Gregory Diamos ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] CUDA port for intel graphics
Hi Gregory, I think most of your questions can be answered by reading the [interface] design document for GEM - the Graphics Execution Manager. http://lwn.net/Articles/283798/ That will give you a better idea of the separation of the execution and memory management which is performed by the kernel and how it is controlled by userspace. All userspace clients are [more or less] equal and submit batch buffers to the kernel to be scheduled for execution. Each batch is a list of buffers [your textures, command streams, vertex buffers etc] which the kernel then maps into the graphics aperture and performs relocations upon the command streams. As such the GPU is then shared between multiple independent clients. If you want to perform a privileged operation such as modifying the ring buffer or registers prior to the execution of your batch, you will need to extend the GEM interface to allow you to do so. Hope this helps, and you have a lot of fun programming with the GPU directly. -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] CUDA port for intel graphics
On Wed, 23 Jun 2010 00:14:39 -0700, Gregory Diamos gregory.dia...@gatech.edu wrote: 1. Is there an interface for writing directly to the GPU ring buffer that is exposed by the driver? If not, would it be straightforward to add such an interface? Take a look at 'drm' in the mesa git repository; that contains a library (libdrm) which provides to ability to execute arbitrary commands in the GPU with in-kernel memory management. This is used by the X 2D driver, the Mesa GL driver and the VaAPI library. git clone git://anongit.freedesktop.org/git/mesa/drm 2. Are there any restrictions (security, DRM, etc) for loading/executing binaries on the media pipeline? Nope. You need permission to open the device, which is currently managed by having a connection to the X server, so for now you'd have to be running under X. There's no requirement to deal with X other than authenticating access to the device though. It would be useful to fix this so that arbitrary programs could use the GPU without needing to be authenticated through the window system. 3. How modular is the driver? Is there an interface for user-level applications to issue hardware commands in a way that is isolated and time-shared with commands from the graphics driver? If not, would it be straightforward to modify the driver to disable the graphics components of the driver and retain only an interface for passing commands to the device? Yes, that's precisely what the DRM infrastructure provides -- the ability to execute arbitrary commands on the hardware from multiple programs at the same time. 4. How is memory sharing between the CPU and GPU handled? Is it possible to map memory from the CPU's address space into the GPU's address space? Sorry if this is already documented somewhere, I might have missed it. As above, the kernel is used to manage memory objects and the driver knows how to deal with the lack of hardware cache coherency with help From the application. -- keith.pack...@intel.com pgp2IgAoX7BoD.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [ANNOUNCE] xf86-video-intel 2.11.901
On Mon, 21 Jun 2010 16:32:48 -0400 Andrew Lutomirski l...@mit.edu wrote: On Sun, Jun 20, 2010 at 11:29 AM, Andrew Lutomirski l...@mit.edu wrote: On Fri, Jun 18, 2010 at 4:04 PM, Jesse Barnes jbar...@virtuousgeek.org wrote: On Thu, 17 Jun 2010 19:44:10 -0700 Jesse Barnes jbar...@virtuousgeek.org wrote: On Fri, 18 Jun 2010 02:20:23 +0200 Marc Deop i Argemà damnsh...@gmail.com wrote: On Friday June 18 2010 02:17:53 Andrew Lutomirski wrote: Neither patch applies for me. One of them do apply for me, the other one doesn't. Testing done on latest 2.6.35-rc3, the building fails. Arg, ok, I'll refresh them and post new ones tomorrow. Ok here are some updated ones. Running these patches on 2.6.35-rc3 (plus the brown-paper-bag TCP fix, plus my hotplug_mask hack, plus my CRT regression fix) with xf86-video-intel be55066c6481b4c5e2cd39ef1c0f3be88cae0c93 (which is about a day old) seems stable and I don't have any visible corruption. Just froze again. I moved my mouse and the screen turned black except for the mouse cursor and a little underscore in the top left that looked like the fbcon cursor. Again, magic sysrq didn't work, which I'd imagine would help narrow things down (presumably, no matter how hard the graphics hardware gets wedged, magic sysrq should still work). Yeah means the GMCH itself probably hung, possibly not responding to memory requests from the CPU. The display was otherwise idle when it froze? The behavior you describe sounds like a panic; there's a patch available to get some more info in that case: vt/console: try harder to print output when panicing that Dave Airlie just posted (attached). Can you apply it as well and see if you can reproduce the problem? Thanks, -- Jesse Barnes, Intel Open Source Technology Center [PATCH] vt_console: try harder to print output when panicing Description: Binary data ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
