Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
Graphics

OpenGL 4.4 and OpenCL 2.0 Specs Released 66

Posted by Unknown Lamer
from the supercomputer-in-a-slot dept.
Via Ars comes news that the OpenGL 4.4 and OpenCL 2.0 were released yesterday. OpenGL 4.4 features a few new extensions, perhaps most importantly a few to ease porting applications from Direct3D. New bindless shaders have access to the entire virtual address space of the card, and new sparse textures allow streaming tiles of textures too large for the graphics card memory. Finally, the ARB has announced the first set of conformance tests since OpenGL 2.0, so going forward anything calling itself OpenGL must pass certification. The OpenCL 2.0 spec is still provisional, but now features a memory model that is a subset of C11, allowing sharing of complex data between the host and GPU and avoiding the overhead of copying data to and from the GPU (which can often make using OpenCL a losing proposition). There is also a new spec for an intermediate language: "'SPIR' stands for Standard Portable Intermediate Representation and is a portable non-source representation for OpenCL 1.2 device programs. It enables application developers to avoid shipping kernel source and to manage the proliferation of devices and drivers from multiple vendors. OpenCL SPIR will enable consumption of code from third party compiler front-ends for alternative languages, such as C++, and is based on LLVM 3.2. Khronos has contributed open source patches for Clang 3.2 to enable SPIR code generation." For full details see Khronos's OpenGL 4.4 announcement, and their OpenCL 2.0 announcement. Update: 07/23 20:17 GMT by U L : edxwelch notes that Anandtech published notes and slides from the SIGGRAPH announcement.
This discussion has been archived. No new comments can be posted.

OpenGL 4.4 and OpenCL 2.0 Specs Released

Comments Filter:
  • Better Article (Score:5, Informative)

    by edxwelch (600979) on Tuesday July 23, 2013 @03:11PM (#44364703)
    • by Anonymous Coward

      The author of that Anandtech story wrote the following in response to a question about the feature gap between DX11.2 and OpenGL 4.4;

      At a high level the two are roughly equivalent. With compute shaders in OpenGL 4.3 there is no longer a significant feature gap for reimplmenting D3D11 in OpenGL. I didn't cover this in the article since it's getting into the real minutia, but 4.4 further improves on that in part by adding a new vertex packing format (GL_ARB_vertex_type_10f_11f_11f_rev) that is equivalent to one that is in D3D. Buffer storage also replicates something D3D does.

      Glad to see OpenGL at parity, or close to it, with Microsoft's 3D stack. One wonders if that is due to the huge growth in OpenGL utilization by mobile platforms, even though those often use only embedded OpenGL profiles.

      • by Kjella (173770)

        Glad to see OpenGL at parity, or close to it, with Microsoft's 3D stack. One wonders if that is due to the huge growth in OpenGL utilization by mobile platforms, even though those often use only embedded OpenGL profiles.

        Well, that depends on what level you're talking about. At the bottom level is of course the hardware, which will have the exact same features so on the top level declaring an API that does the same is not that hard. The hard part is everything in the middle, which is why OpenGL is now up to version 4.4 while Mesa (the open source implementation) still only supports version 3.1 from March 2009, so that "feature parity" OpenGL version is only available using proprietary blobs. What the packing formats and suc

      • by Bengie (1121981)
        I've been a pro-DX11 guy, but GO OpenGL. Nice. I hope some new Linux Steam game comes out to make use of this stuff soon(tm).
        • by Anonymous Coward

          I've been a pro-DX11 guy, but GO OpenGL. Nice. I hope some new Linux Steam game comes out to make use of this stuff soon(tm).

          I've been a pro OpenGL guy forever but only because I found it easier to play with and more open but we all knew DirectX was massively better at this stuff for years. I've spent the last 3 months relearning everything i know to go from 1.x to 3.3 to 4.0 code. It actually is very fun to throw weeks to years worth of work away as l realize i'm years behind and of course it is extremely powerful on all the levels DirectX is now with respect to talking to a GPU. It still is sort of like banging your head on

      • by gman003 (1693318)

        They're essentially at parity because they're matching, for the most part, the features of the underlying hardware. It's a weird give-and-take - Microsoft likes to dictate features, but their DirectX team is smart enough (now) to dictate features that at least one of the GPU companies is already implementing - essentially, they ask Nvidia what they're adding, ask AMD what they're adding, then add both of them to Direct3D and tell them both to implement it (and since they're both watching each other's moves

  • the important question is... when we will see it delivered on Linux drivers?
  • That's surprisingly uncommon among standardization organizations. I wish IETF could do the same for RFCs...

Building translators is good clean fun. -- T. Cheatham

Working...