>> Sunday, March 29, 2015

Edit: As of 4/9, it looks like the Intel-Altera buyout discussions have come to a halt.

There's been no official word, but reputable sources are reporting that Intel is taking steps to buy Altera. In all likelihood, this is related to Intel's plan to integrate FPGA fabric into their upcoming Xeon processors. I've discussed this before (here and here).

I'll be surprised if Intel allows developers to access the FPGA fabric with traditional design languages like VHDL or Verilog. It would be safer to provide access through OpenCL kernels. That is, a design based on a simple procedure wouldn't be as susceptible to low-level issues like race conditions or clock skew. Still, current FPGA design tools are expensive (especially Altera's) and it can take hours to convert any type of design to an FPGA bitstream.

I'm particularly curious whether Intel will allow partial reconfiguration of the FPGA fabric. A long time ago, I worked on a DARPA project to implement cognitive modeling with FPGAs, and I became fascinated with the field of reconfigurable computing. Personally, I think hard artificial intelligence will only become realizable when devices are capable of rewiring their internal circuitry.

>> Wednesday, March 18, 2015

AMD just released the programming guide and reference for the Mantle API (PDF). This should give us an idea of what the Vulkan API will be like.

I've only skimmed the document so far, but I'm surprised by how much Mantle resembles OpenCL and how little it resembles OpenGL. GPUs are represented by device structures that receive data packaged in memory objects. "Commands are sent to the GPU by recording them in command buffers and submitting command buffers to the GPU queues." Sounds familiar.

Mantle provides lower-level access to GPUs than OpenCL. It's reasonable to assume that a well-coded Mantle/Vulkan compute application will outperform a comparably well-coded OpenCL application. Of course, this only applies to applications that target GPUs.

Mantle has a window system interface specifically for the Windows operating system. Interesting. I wonder if Vulkan will have similar interfaces for different operating systems.

>> Sunday, March 15, 2015

Recently, I came up with an idea for a commercial desktop application. It's cross-platform, so I planned to use Qt as the framework. Qt is released under two licenses: a commercial license and the LGPL. The LGPL states that Qt can be freely distributed in an application so long as the libraries are kept separate. But I don't mind paying for quality, so I called the Qt Company to ask about the commercial license.

The least expensive commercial license costs over $300 a month. No technical support. That's pocket change for a large company, but it's beyond my reach and that of many small businesses. In contrast, Microsoft sells its toolset for a one-time cost of $500, making Windows development significantly more cost-effective.

Now I'm considering wxWidgets and GTK+, but I'd rather use Qt. It's polished and well-documented, and I've never encountered any errors or issues with performance. The developer base is vast, with coders across the world fixing bugs and adding their own extensions.

Valve is deeply interested in promoting Linux, so I think they should buy Qt and release it under a license like the MIT License or BSD License. This would give coders, corporations, and entrepreneurs a good reason to choose cross-platform development over Windows-only development. It would also give Valve and the Khronos Group a framework with which to showcase their new toolsets.

At present, Valve is focused on developing and distributing games. But there's no reason that Steam can't be used to distribute general applications. I'd be happy to pay Valve to distribute my product if they made sure it couldn't be pirated.

One last thing. Vulkan can render graphics inside of an application's window, but it can't provide the window. Basic frameworks like GLUT are fine for newcomers, but professional developers need more. Qt meets these needs, and if Qt supported Vulkan before anyone else, it would be a major step forward for open-source development.

>> Sunday, March 8, 2015

I've read the slides (PDF) from the presentations on Vulkan, and I've learned a great deal. But two things puzzle me. First, it's clear that Vulkan is intended to replace OpenGL, but nothing I've read suggests that it may replace OpenCL. But how can a compute-only language stay relevant when a graphics-and-compute language is available?

One important distinction is that, unlike Vulkan, OpenCL runs on devices that aren't GPUs. Intel has an OpenCL SDK for their CPUs and Altera has an SDK for their FPGAs. I've read that Texas Instruments is working on an SDK for their digital signal processors (DSPs). Still, the OpenCL developer base is so small and the API is so complex that I wonder if it's worth the effort.

My second question involves Nvidia. They've spent many years and millions of dollars trying to convince people that CUDA is the language for GPU computation. What do they gain by supporting Vulkan? I'm sure Vulkan will never approach CUDA in features or performance on Nvidia hardware, but it still seems odd to hear their representatives praising a competing language.

>> Tuesday, March 3, 2015

The Khronos Group has announced that Vulkan (formerly known as glNext) will provide "high-efficiency access to graphics and compute on modern GPUs." From the look of it, Vulkan will effectively supersede OpenGL, OpenCL, CUDA, Direct3D, and Mantle for GPU development. The API won't be released until later in the year, but Valve will provide a preview at the Game Developers Conference.

I think this is wonderful. I shouldn't need three languages to program one processor. Further, OpenGL has become so bloated and high-level that it's next to impossible to know how efficiently an application will run. And though I loved OpenCL-OpenGL interoperability, it annoyed me that the CPU had to tell the GPU when to switch between OpenCL kernels and OpenGL shaders.

Most of the major hardware vendors have endorsed Vulkan, but I haven't heard anything from Google. That's a shame. Chrome won't run WebCL in any way and the only GPU compute language supported by Android is Renderscript. If Google would get on board with Vulkan, it would be a fine thing.

In other news, the Khronos Group has released a provisional spec for OpenCL 2.1. From the announcement, the major change is that kernels can be coded with C++. The link to the PDF is here.