| '''OpenGL extension ARB.compute_shader |
| |
| This module customises the behaviour of the |
| OpenGL.raw.GL.ARB.compute_shader to provide a more |
| Python-friendly API |
| |
| Overview (from the spec) |
| |
| Recent graphics hardware has become extremely powerful and a strong desire |
| to harness this power for work (both graphics and non-graphics) that does |
| not fit the traditional graphics pipeline well has emerged. To address |
| this, this extension adds a new single-stage program type known as a |
| compute program. This program may contain one or more compute shaders |
| which may be launched in a manner that is essentially stateless. This allows |
| arbitrary workloads to be sent to the graphics hardware with minimal |
| disturbance to the GL state machine. |
| |
| In most respects, a compute program is identical to a traditional OpenGL |
| program object, with similar status, uniforms, and other such properties. |
| It has access to many of the same resources as fragment and other shader |
| types, such as textures, image variables, atomic counters, and so on. |
| However, it has no predefined inputs nor any fixed-function outputs. It |
| cannot be part of a pipeline and its visible side effects are through its |
| actions on images and atomic counters. |
| |
| OpenCL is another solution for using graphics processors as generalized |
| compute devices. This extension addresses a different need. For example, |
| OpenCL is designed to be usable on a wide range of devices ranging from |
| CPUs, GPUs, and DSPs through to FPGAs. While one could implement GL on these |
| types of devices, the target here is clearly GPUs. Another difference is |
| that OpenCL is more full featured and includes features such as multiple |
| devices, asynchronous queues and strict IEEE semantics for floating point |
| operations. This extension follows the semantics of OpenGL - implicitly |
| synchronous, in-order operation with single-device, single queue |
| logical architecture and somewhat more relaxed numerical precision |
| requirements. Although not as feature rich, this extension offers several |
| advantages for applications that can tolerate the omission of these |
| features. Compute shaders are written in GLSL, for example and so code may |
| be shared between compute and other shader types. Objects are created and |
| owned by the same context as the rest of the GL, and therefore no |
| interoperability API is required and objects may be freely used by both |
| compute and graphics simultaneously without acquire-release semantics or |
| object type translation. |
| |
| The official definition of this extension is available here: |
| http://www.opengl.org/registry/specs/ARB/compute_shader.txt |
| ''' |
| from OpenGL import platform, constant, arrays |
| from OpenGL import extensions, wrapper |
| import ctypes |
| from OpenGL.raw.GL import _types, _glgets |
| from OpenGL.raw.GL.ARB.compute_shader import * |
| from OpenGL.raw.GL.ARB.compute_shader import _EXTENSION_NAME |
|
|
| def glInitComputeShaderARB(): |
| '''Return boolean indicating whether this extension is available''' |
| from OpenGL import extensions |
| return extensions.hasGLExtension( _EXTENSION_NAME ) |
|
|
|
|
| |
