On Tue, 3 Feb 2009, Ross Ridge wrote: > Mark Mitchell writes: > >That's correct. I was envisioning a proper compiler that would take > >OpenCL input and generate binary output, for a particular target, just > >as with all other GCC input languages. That target might be a GPU, or > >it might be a multi-core CPU, or it might be a single-core CPU. > > I have a hard time seeing why this would be all that worthwhile. > Since the instruction sets for AMD, NVIDIA or current Intel GPUs are > trade scretes, GCC won't be able to generate binary output for them. > OpenCL is designed for heterogenous systems, compiling for multi-core or > single-core CPUs would only be useful as a cheap fallback implementation. > This limits a GCC-based OpenGL implementation to achieving it's primary > purpose with just Cell processors and maybe Intel's Larrabee. Is that > what you envision? Without AMD/NVIDIA GPU support it doesn't sound all > that useful to me.
The AMD instruction sets now have public documentation. Other manufacturers may well follow suit, especially if enough people caring about free software and open documentation choose which GPU to buy on such a basis (which is obviously a personal choice for them). In any case, public documentation is not required. There are many examples of free software developed by a developer who has documentation provided under an NDA that allows the release of free software embodying certain information from that documentation (this is common for device drivers if there is no manual with just the information relevant for device drivers, just an NDA manual with much more internal information about the device). So as per the policy established at <http://gcc.gnu.org/ml/gcc/2005-06/msg00134.html>, a GPU manufacturer could provide privately the information required to create a GCC port for their GPU without releasing their documentation publically (much as releasing that documentation publically would have obvious advantages to the community). -- Joseph S. Myers jos...@codesourcery.com
