The support of user clipping planes has been added to GLSL Hacker 0.8.0+. User clipping planes are very easy to use: you need a GLSL program that deals with gl_ClipDistance and you need to enable one of the available user clipping planes with gh_renderer.enable_state("GL_CLIP_DISTANCE0").

A demo is available in the host_api/Clip_Planes/ folder of the code sample pack v2.25.0.

One of the coolest features of GLSL Hacker 0.8.0 is the support of FreeType GL via a dedicated plugin. Thanks to this new plugin, GLSL Hacker can now load any TTF (True Type Font) or OTF (Open Type Font) file. I also added a small Lua lib (gx_font.lua in the libs/lua/ folder of glsl hacker) to make things easier.

One thing we wanted to improve upon with GRID Autosport was our trackside environments, in particular the grass. The old system had served us well but it was time for an improvement so step up Rich Kettlewell, one of our programming wizards who set about the task of doing just that.

Below you’ll find a brief presentation which goes into how we achieved this and the effects it has on the game itself. The presentation was given at the Develop conference and while it was originally meant for game developers we hope you enjoy taking a look at what goes on behind the scenes.

October 20th, 2014, – The Khronos™ Group today announced the ratification and public release of the finalized OpenVX™ 1.0 specification, an open, royalty-free standard for cross platform acceleration of computer vision applications. OpenVX enables performance and power-optimized computer vision processing, especially important in embedded and real-time uses cases such as face, body and gesture tracking, smart video surveillance, advanced driver assistance systems (ADAS), object and scene reconstruction, augmented reality, visual inspection, robotics and more. In addition to the OpenVX specification, Khronos has developed a full set of conformance tests and an Adopters Program, that enables implementers to test their implementations and use the OpenVX trademark if conformant. Khronos plans to ship an open source, fully-conformant CPU-based implementation of OpenVX 1.0 before the end of 2014. The full OpenVX 1.0 specification and details about the OpenVX Adopters Program are available at www.khronos.org/openvx.

OpenVX defines a higher level of abstraction for execution and memory models than compute frameworks such as OpenCL™, enabling significant implementation innovation and efficient execution on a wide range of architectures while maintaining a consistent vision acceleration API for application portability. An OpenVX developer expresses a connected graph of vision nodes that an implementer can execute and optimize through a wide variety of techniques such as: acceleration on CPUs, GPUs, DSPs or dedicated hardware, compiler optimizations, node coalescing, and tiled execution to keep sections of processed images in local memories. This architectural agility enables OpenVX applications on a diversity of systems optimized for different levels of power and performance, including very battery-sensitive, vision-enabled, wearable displays.

“Increasingly powerful and efficient processors and image sensors are enabling engineers to incorporate visual intelligence into a wide range of systems and applications,” said Jeff Bier, founder of the Embedded Vision Alliance. “A key challenge for engineers is efficiently mapping complex algorithms onto the processor best suited to the application. OpenVX is an important step towards easing this challenge.”

The precisely defined specification and conformance tests for OpenVX make it ideal for deployment in production systems, where cross-vendor consistency and reliability are essential. OpenVX is complementary to the popular OpenCV open source vision library that is also used for application prototyping but is not so tightly defined and lacks OpenVX graph optimizations. Khronos has defined the VXU™ utility library to enable developers to call individual OpenVX nodes as standalone functions for efficient code migration from traditional vision libraries such as OpenCV. Finally, as any Khronos specification, OpenVX is extensible to enable nodes to be defined and deployed to meet customer needs, ahead of being integrated into the core specification.

Currently, I didn't manage to get the GPU acceleration on Linux (Mint 17 64-bit). I tested with latest R331.104 and with R340.xx. There is a cuInit failure (I installed the latest CUDA toolkit v6.5.14). The cuInit failure is also present with PhysX SDK samples.

Here are some benchmark numbers with GPU PhysX (currently only under Windows) and CPU PhysX (Windows and Linux).

To force CPU PhysX, just edit the demo file (demo_gl2_v1.xml) and update the line 182:

qu3e is a compact, light-weight and fast 3D physics engine in C++. It is has been specifically created to be used in games. It is portable with no external dependencies other than various standard c header files (such as cassert and cmath). qu3e is designed to have an extremely simple interface for creating and manipulating rigid bodies.

qu3e is of particular interest to those in need of a fast and simple 3D physics engine, without spending too much time learning about how the whole engine works. In order to keep things very simple and friendly for new users, only box collision is supported. No other shapes are supported (capsules and spheres may be added in the future if requested).

Since qu3e is written in C++ is intended for users familiar with C++. The inner-code of qu3e has quite a few comments and is a great place for users to learn the workings of a 3D physics engine.

qu3e stands for "cube", since the 3 looks slightly like the letter b and boxes (or cubes!) are the primary type of collision object.

I struggled many hours recently with subroutines and I didn't manage to make them ok under OS X with a GeForce GPU.I added a new simple demo that shows a pqtorus rendered three times, each time with a different subroutine (texture, phong, phong+texture).

The demo is available in the code sample pack: host_api/gl-400-arb-shader-subroutine/demo_gl4_v3.xml

The demo works fine on Windows. On OS X, the demo works fine for Intel and AMD GPUs but not for NVIDIA GPUs. With the GT650M / OSX, the same subroutine is used to shade all meshes and that's the bug. I suspect a bug on OSX with GeForce GPUs because the demo works fine everywhere else. But since it's a NVIDIA related issue, my code can be also guilty...

I am extremely happy to announce that Qt 5.4 Beta is now available for download. There are a lot of new and interesting things in Qt 5.4 and I will try to summarize the most important highlights in this blog post.

Qt 5.4 brings capability to dynamically select during the application startup whether to use ANGLE or OpenGL on Windows. It is possible to use either opengl32.dll or ANGLE’s OpenGL ES 2.0 implementation in Qt applications without the need for two separate builds of the binaries. This significantly simplifies the task of creating Qt Quick applications for Windows PCs. Dynamic GL switching is not yet enabled in the prebuilt Qt 5.4 Beta binaries. In addition to these, there is a large number of smaller improvements and bug fixes for the Windows port in Qt 5.4.

...

QOpenGLContext is now able to adopt existing native contexts (EGL, GLX, …). This allows interoperability between Qt and other frameworks, such as game engines.

When it comes to AMD FirePro™ S-Series GPUs, there is never “too much of a good thing.” During my conversations at trade shows and conventions, customers have been asking for a server GPU solution that not only provides the speed to accomplish computational tasks, but they also want accuracy for precise results. Earlier this year, we announced the top-of-line AMD FirePro™ S9150 – the most powerful server GPU ever built for High Performance Computing1 measured by performance/watt. But customers also told us they want a product for mainstream, budget conscious projects that still delivers equally exceptional performance for HPC.

To meet that demand, we’ve expanded our server GPU portfolio. By infusing our most current iteration of the AMD GCN architecture2 into AMD FirePro™ server GPUs, we have been able to offer two products that deliver leading edge double-precision floating-point rates, and operate with tremendous efficiency.

The new AMD FirePro™ S9100 server GPU is supreme in its class, with high peak single- and double-precision floating point performance, including 2.11 TFLOPS peak double-precision and up to 9.4 GFLOPS per watt TDP double-precision performance3. Compute-intensive workloads are where this card excels. With 2,560 stream processors and 12GB of GDDR5 memory, the AMD FirePro S9100 is equipped to handle supercomputing tasks. For those working in scientific compute, research, or structural analysis, it would be fair to say this GPU is a compute powerhouse. On top of the performance, the card’s maximum TDP comes in at 225W, and its passive cooling solution makes it ideal for deployment in server environments.

Version 0.7.1.1 - 2014.09.29----------------------------! updated network script updater (v0.2.0, Windows and OSX) with live coding checkbox and execute button.! fixed some bugs and improved the live coding in the Windows version.+ added auto-save of scripts and shaders if necessary (read: they have been modified). + added a button in script and shader editors to save the code source in the scripts/ or shaders/ folder of GLSL Hacker (Windows version only).* script and shaders errors are now correctly redirected to the output window.+ added an option to disable live coding in script and shader editing windows (Windows version only).* fixed some potential crashes in gh_utils functions that take strings as parameters (like font_render() or font_render_3d().! updated the dialog box / output window for the traces (Windows version only).+ added circle_create(), circle_update_radius(), line_create(), line_set_start_position(), line_set_end_position(), line_set_start_color() and line_set_end_color() to gh_utils lib.! updated the Lua immediate mode: now the Lua state of the first script is used (not the case so far!). * improved the GPU monitoring plugin when running on NVIDIA Optimus systems.+ added gh_leap (Leap Motion) library in the Python plugin.+ updated Python plugin: gh_renderer.get_capability_4i(), gh_renderer.query_xxxx() (GL_ARB_pipeline_statistics_query GL4.5), gh_utils...

GL_NV_framebuffer_mixed_samples and GL_EXT_raster_multisample - target-independent multisampling control and mixed samples: this feature adds a lot of flexibility to the multi-sampled rasterization, and decouples the rasterization sampling frequency (which can be set explicitly) from the actual framebuffer storage. It enables rasterization to operate at higher sampling frequency than the number of samples in the target color render buffers, and it supports both depth and stencil testing at this frequency, if the corresponding depth and stencil buffers are sampled accordingly (it must be a multiple of the number of samples in the color buffers).

GL_NV_fragment_coverage_to_color - coverage to color conversion: this allows using ROP to automatically convert the post depth-/stencil-/alpha- test coverage mask into a color and write it into a color render target.

GL_EXT_post_depth_coverage - post-depth coverage: this extension allows the fragment shader to get the post depth-test coverage mask of the current fragment as input (gl_SampleMaskIn[]).

GL_NV_sample_mask_override_coverage - multisample coverage override: the standard GL behavior for FS output coverage mask (gl_SampleMask[]) is to AND it with the actual primitive input coverage mask. This extension disables this operation.

GL_NV_geometry_shader_passthrough - geometry shader passthrough: this extension allows to write more efficient geometry shaders in the case there is a one-to-one mapping between input and output primitives.

GL_EXT_sparse_texture2: Enhanced sparse textures: this new extension adds the ability to retrieve texture access residency information from GLSL, to specify minimum allocated LOD to texture fetches and to return a constant zero value for lookups into unallocated pages.

GL_NV_shader_atomic_fp16_vector - FP16 global atomics: This extension provides a set of new atomic operations operating on 2 and 4 components vectors of 16b floating point values for images, bindless pointers to global memory and storage buffers.