Subject: General Tech | June 4, 2018 - 10:12 PM | Scott Michaud
Tagged: opengl, opencl, apple
Apple has just announced that OpenGL and OpenCL are deprecated for all Apple platforms, starting with macOS 10.14 and iOS 12. The APIs are still available on these operating systems, but their development tools will apparently start to nag you about using it and, eventually, it could disappear. Instead, Apple wants users to move to their Metal API.
This kinda bites.
I have a couple thoughts about this.
First, of course, relying upon Apple for APIs if you’re expecting to make a timeless work of art… is a bad idea. They are not quite as bad as a console could be, and Microsoft has been flirting with killing Win32 since Windows 8, but you shouldn’t expect that your content will be around forever. They do stuff like this. This is the stuff they do. I know I’ve said it before, but they’ve even sent the Khronos Group a legal notice for attempting to expand the usage of OpenCL, which they own the trademark and several patents for. It’s fine to use Apple products and platforms, but don’t be shocked when stuff like this happens.
Second, I wonder how much of this has to do with the Imagination Technologies announcement from last year. At the time, I said, “Apple already has their own low-level graphics API, Metal, so they might have a lot to gain, although some macOS and iOS applications use OpenGL and OpenGL ES. We’ll find out in less than two years.”
One year later, and it looks like part of Apple’s strategy was, in fact, to deprecate OpenGL and OpenGL ES. I can see a tiny chance that Apple will, in the future, release GPUs that cannot run OpenGL / OpenGL ES / OpenCL software, because they want to own the whole stack from software to hardware. This sounds like something Apple would do, although I’m not sure if owning their own GPU is enough of a draw for them. After all, they will be fighting against an industry that uses PC-compatible hardware, so it runs the risk of stagnating like a lot of RISC companies (except ARM, which was also a battleground of multiple vendors) that just couldn’t keep up to the x86 war.
But it seems like something Apple would do… I don’t know.
Third, this announcement lines up well with recent Valve’s Vulkan-through-Metal (via MoltenVK) release through Dota2. I’m now wondering what Valve was trying to accomplish by pushing that news out five days before Apple pushed against OpenGL. You would think that Valve would have to have known about this, and timed their announcement appropriately… but to what effect?
So those are my three thoughts. What do you think?
Subject: Graphics Cards | February 18, 2018 - 02:54 PM | Scott Michaud
Tagged: opengl, nvidia, metal, macos, apple
Just two days ago, NVIDIA has published a job posting for a software engineer to “implement and extend 3D graphics and Metal”. Given that they specify the Metal API, and they want applicants who are “Experienced with OSX and/or Linux operating systems”, it seems clear that this job would involve macOS and/or iOS.
First, if this appeals to any of our readers, the job posting is here.
Second, and this is where it gets potentially news-worthy, is that NVIDIA hasn’t really done a whole lot on Apple platforms for a while. The most recent NVIDIA GPU to see macOS is the GeForce GTX 680. It’s entirely possible that NVIDIA needs someone to fill in and maintain those old components. If that’s the case? Business as usual. Nothing to see here.
The other possibility is that NVIDIA might be expecting a design win with Apple. What? Who knows. It could be something as simple as Apple’s external GPU architecture allowing the user to select their own add-in board. Alternatively, Apple could have selected an NVIDIA GPU for one or more product lines, which they have not done since 2013 (as far as I can tell).
Apple typically makes big announcements at WWDC, which is expected in early June, or around the back-to-school season in September. I’m guessing we’ll know by then at the latest if something is in the works.
Subject: Graphics Cards | August 2, 2017 - 07:01 AM | Scott Michaud
Tagged: spir-v, opengl, Khronos
While Vulkan has been getting a lot of mindshare recently, OpenGL is still in active development. This release, OpenGL 4.6, adds a bunch of extensions into the core specification, making them more reliably available to engines. There’s a lot of them this time, many of which seem to borrow design elements from the work done on Vulkan.
The headlining feature is SPIR-V support as an ARB extension, which frees OpenGL programs from having their shaders written in GLSL. Many engines write their shaders in HLSL and use a transpiler to generate the corresponding GLSL, which may not support all features. The extension might also help titles target both OpenGL and Vulkan, although I’m not sure why we would see a driver that supports OpenGL 4.6 but not Vulkan.
Another extension is GL_KHR_no_error, which tells graphics drivers that they do not need to generate errors at runtime. This will save a bit of driver overhead. GL_ARB_indirect_parameters also helps with CPU overhead by allowing draws to pass parameters to other GPU-initiated draws, although this is a bit out of my domain. Also, if you’re not working in SPIR-V, GL_KHR_parallel_shader_compile will allow the driver to compile your GLSL shaders across multiple worker threads.
NVIDIA has a beta driver for developers, which is a couple of versions back compared to their consumer version, so you don’t want to install it unless you intend on developing OpenGL 4.6 applications. Mesa says that they shouldn’t be too far behind.
An Data Format for Whole 3D Scenes
The Khronos Group has finalized the glTF 2.0 specification, and they recommend that interested parties integrate this 3D scene format into their content pipeline starting now. It’s ready.
glTF is a format to deliver 3D content, especially full scenes, in a compact and quick-loading data structure. These features differentiate glTF from other 3D formats, like Autodesk’s FBX and even the Khronos Group’s Collada, which are more like intermediate formats between tools, such as 3D editing software (ex: Maya and Blender) and game engines. They don’t see a competing format for final scenes that are designed to be ingested directly, quick and small.
glTF 2.0 makes several important changes.
The previous version of glTF was based on a defined GLSL material, which limited how it could be used, although it did align with WebGL at the time (and that spurred some early adoption). The new version switches to Physically Based Rendering (PBR) workflows to define their materials, which has a few advantages.
First, PBR can represent a wide range of materials with just a handful of parameters. Rather than dictating a specific shader, the data structure can just... structure the data. The industry has settled on two main workflows, metallic-roughness and specular-gloss, and glTF 2.0 supports them both. (Metallic-roughness is the core workflow, but specular-gloss is provided as an extension, and they can be used together in the same scene. Also, during the briefing, I noticed that transparency was not explicitly mentioned in the slide deck, but the Khronos Group confirmed that it is stored as the alpha channel of the base color, and thus supported.) Because the format is now based on existing workflows, the implementation can be programmed in OpenGL, Vulkan, DirectX, Metal, or even something like a software renderer. In fact, Microsoft was a specification editor on glTF 2.0, and they have publicly announced using the format in their upcoming products.
The original GLSL material, from glTF 1.0, is available as an extension (for backward compatibility).
A second advantage of PBR is that it is lighting-independent. When you define a PBR material for an object, it can be placed in any environment and it will behave as expected. Noticeable, albeit extreme examples of where this would have been useful are the outdoor scenes of Doom 3, and the indoor scenes of Battlefield 2. It also simplifies asset creation. Some applications, like Substance Painter and Quixel, have artists stencil materials onto their geometry, like gold, rusted iron, and scuffed plastic, and automatically generate the appropriate textures. It also aligns well with deferred rendering, see below, which performs lighting as a post-process step and thus skip pixels (fragments) that are overwritten.
PBR Deferred Buffers in Unreal Engine 4 Sun Temple.
Lighting is applied to these completed buffers, not every fragment.
glTF 2.0 also improves support for complex animations by adding morph targets. Most 3D animations, beyond just moving, rotating, and scaling whole objects, are based on skeletal animations. This method works by binding vertexes to bones, and moving, rotating, and scaling a hierarchy of joints. This works well for humans, animals, hinges, and other collections of joints and sockets, and it was already supported in glTF 1.0. Morph targets, on the other hand, allow the artist to directly control individual vertices between defined states. This is often demonstrated with a facial animation, interpolating between smiles and frowns, but, in an actual game, this is often approximated with skeletal animations (for performance reasons). Regardless, glTF 2.0 now supports morph targets, too, letting the artists make the choice that best suits their content.
Speaking of performance, the Khronos Group is also promoting “enhanced performance” as a benefit of glTF 2.0. I asked whether they have anything to elaborate on, and they responded with a little story. While glTF 1.0 validators were being created, one of the engineers compiled a list of design choices that would lead to minor performance issues. The fixes for these were originally supposed to be embodied in a glTF 1.1 specification, but PBR workflows and Microsoft’s request to abstract the format away from GLSL lead to glTF 2.0, which is where the performance optimization finally ended up. Basically, there wasn’t just one or two changes that made a big impact; it was the result of many tiny changes that add up.
Also, the binary version of glTF is now a core feature in glTF 2.0.
The slide looks at the potential future of glTF, after 2.0.
Looking forward, the Khronos Group has a few items on their glTF roadmap. These did not make glTF 2.0, but they are current topics for future versions. One potential addition is mesh compression, via the Google Draco team, to further decrease file size of 3D geometry. Another roadmap entry is progressive geometry streaming, via Fraunhofer SRC, which should speed up runtime performance.
Yet another roadmap entry is “Unified Compression Texture Format for Transmission”, specifically Basis by Binomial, for texture compression that remains as small as possible on the GPU. Graphics processors can only natively operate on a handful of formats, like DXT and ASTC, so textures need to be converted when they are loaded by an engine. Often, when a texture is loaded at runtime (rather than imported by the editor) it will be decompressed and left in that state on the GPU. Some engines, like Unity, have a runtime compress method that converts textures to DXT, but the developer needs to explicitly call it and the documentation says it’s lower quality than the algorithm used by the editor (although I haven’t tested this). Suffices to say, having a format that can circumvent all of that would be nice.
Again, if you’re interested in adding glTF 2.0 to your content pipeline, then get started. It’s ready. Microsoft is doing it, too.
Subject: Graphics Cards | May 10, 2017 - 03:53 AM | Scott Michaud
Tagged: vulkan, ShadowPlay, opengl, nvidia, geforce experience
The latest version of GeForce Experience, 3.6, adds video capture (including screenshots and live streaming) support for OpenGL and Vulkan games. The catalog of titles support by ShadowPlay, which I’m pretty sure NVIDIA wants to call Share now, despite referring to it by its old name in the blog post, now includes No Man’s Sky, DOOM, and Microsoft’s beloved OpenGL title: Minecraft.
The rest of the update focuses on tweaking a few interface elements, including its streaming panel, its video and screenshot upload panel, and its gallery. Access to the alternative graphics APIs was the clear headline-maker, however, opening the door to several large gaming groups, and potentially even more going forward.
Subject: Graphics Cards | April 3, 2017 - 03:15 PM | Jeremy Hellstrom
Tagged: mad max, linux, kepler, maxwell, pascal, NVIDA, vulkan, opengl
With Vulkan support being added to Mad Max, at least in beta form, Phoronix decided to take advantage of the release to test the performance of a wide variety of NVIDIA cards on the API. They grabbed over a dozen cards encompassing three different architectures, from the GTX 680 through to the GTX 1080 Ti, so you get a very good look at the change in performance of NVIDIA on Vulkan. The results are clear, in every case Vulkan was superior to OpenGL and in many cases framerate more than doubled. Drop by for a look at what some predicted was a DOA API.
"Yesterday game porter firm Feral Interactive released a public beta of Mad Max that features a Vulkan renderer in place of its OpenGL API for graphics rendering on Linux. In addition to Radeon Vulkan numbers, I posted some NVIDIA Mad Max Linux benchmarks with both renderers. Those results were exciting on the few Pascal cards tested so I have now extended that comparison to feature a line-up of 14 NVIDIA GeForce graphics cards from Kepler, Maxwell, and Pascal families while looking at this game's OpenGL vs. Vulkan performance."
Here are some more Graphics Card articles from around the web:
Subject: Graphics Cards | November 5, 2016 - 08:19 PM | Scott Michaud
Tagged: linux, DOTA 2, valve, nvidia, vulkan, opengl
Phoronix published interesting benchmark results for OpenGL vs Vulkan on Linux, across a wide spread of thirteen NVIDIA GPUs. Before we begin, the CPU they chose was an 80W Intel Xeon E3-1280 v5, which fits somewhere between the Skylake-based Core i7-6700k and Core i7-6700 (no suffix). You may think that Xeon v5 would be based on Broadwell, but, for some reason, Intel chose the E3-1200 series to be based on Skylake. Regardless, the choice of CPU will come in to play.
They will apparently follow up this article with AMD results.
A trend arose throughout the whole article. At 1080p, everything, from the GTX 760 to the GTX 1080, was rendering at ~101 FPS on OpenGL and ~115 FPS on Vulkan. The obvious explanation is that the game is 100% CPU-bound on both APIs, but Vulkan is able to relax the main CPU thread enough to squeeze out about 14% more frames.
The thing is, the Xeon E3-1280 v5 is about as high-end of a mainstream CPU as you can get. It runs the most modern architecture and it can achieve clocks up to 4 GHz on all cores. DOTA 2 can get harsh on the CPU when a lot of units are on screen, but this is a little surprisingly low. Then again, I don't have any experience running DOTA 2 benchmarks, so maybe it's a known thing, or maybe even a Linux-version thing?
Moving on, running the game at 4K, the results get more interesting. In GPU-bound scenarios, NVIDIA's driver shows a fairly high performance gain on OpenGL. Basically all GPUs up to the GTX 1060 run at a higher frame rate in OpenGL, only switching to Vulkan with the GTX 1070 and GTX 1080, where OpenGL hits that 101 FPS ceiling and Vulkan goes a little above.
Again, it will be interesting to see how AMD fairs against this line of products, both in Vulkan and OpenGL. Those will apparently come “soon”.
Why Two 4GB GPUs Isn't Necessarily 8GB
We're trying something new here at PC Perspective. Some topics are fairly difficult to explain cleanly without accompanying images. We also like to go fairly deep into specific topics, so we're hoping that we can provide educational cartoons that explain these issues.
This pilot episode is about load-balancing and memory management in multi-GPU configurations. There seems to be a lot of confusion around what was (and was not) possible with DirectX 11 and OpenGL, and even more confusion about what DirectX 12, Mantle, and Vulkan allow developers to do. It highlights three different load-balancing algorithms, and even briefly mentions what LucidLogix was attempting to accomplish almost ten years ago.
If you like it, and want to see more, please share and support us on Patreon. We're putting this out not knowing if it's popular enough to be sustainable. The best way to see more of this is to share!
Subject: General Tech | February 18, 2016 - 02:16 PM | Ken Addison
Tagged: x16 LTE, vulkan, video, ssd, Samsung, qualcomm, podcast, pb328q, opengl, nvidia, micron, Khronos, gtx 950, asus, apple, 840 evo, 750ti, 750 evo, 3d nand
PC Perspective Podcast #387 - 02/18/2016
Join us this week as we discuss the ASUS PB328Q, Samsung 750 EVO SSD, the release of Vulkan and more!
The URL for the podcast is: http://pcper.com/podcast - Share with your friends!
- iTunes - Subscribe to the podcast directly through the Store (audio only)
- RSS - Subscribe through your regular RSS reader (audio only)
- MP3 - Direct download link to the MP3 file
Hosts: Ryan Shrout, Jeremy Hellstrom, Josh Walrath, and Allyn Malventano
Program length: 1:34:18
Week in Review:
0:35:00 This episode of the PC Perspective Podcast is brought to you by Audible, the world's leading provider of audiobooks with more than 180,000 downloadable titles across all types of literature including fiction, nonfiction, and periodicals. For your free audiobook, go to audible.com/pcper
News items of interest:
1:07:00 This episode of PC Perspective Podcast is brought to you by Braintree. Even the best mobile app won’t work without the right payments API. That’s where the Braintree v.0 SDK comes in. One amazingly simple integration gives you every way to pay. Try out the sandbox and see for yourself at braintreepayments.com/pcper
Hardware/Software Picks of the Week
Subject: Graphics Cards | December 29, 2015 - 07:05 AM | Scott Michaud
Tagged: opengl, mesa, linux, Intel
The open-source driver for Intel is known to be a little behind on Linux. Because Intel does not provide as much support as they should, the driver still does not support OpenGL 4.0, although that is changing. One large chunk of that API is support for tessellation, which comes from DirectX 11, and recent patches are adding it for supported hardware. Proprietary drivers exist, at least for some platforms, but they have their own issues.
According to the Phoronix article, once the driver succeeds in supporting OpenGL 4.0, it will not be too long to open the path to 4.2. Tessellation is a huge hurdle, partially because it involves adding two whole shading stages to the rendering pipeline. Broadwell GPUs were recently added, but a patch that was committed yesterday will expand that to Ivy Bridge and Haswell. On Windows, Intel is far ahead -- pushing OpenGL 4.4 for Skylake-based graphics, although that platform only has proprietary drivers. AMD and NVIDIA are up to OpenGL 4.5, which is the latest version.
While all of this is happening, Valve is working on an open-source Vulkan driver for Intel on Linux. This API will be released adjacent to OpenGL, and is built for high-performance graphics and compute. (Note that OpenCL is more sophisticated than Vulkan "1.0" will be on the compute side of things.) As nice as it would be to get high-end OpenGL support, especially for developers who want a more simplified structure to communicate to GPUs with, Vulkan will probably be the API that matters most for high-end video games. But again, that only applies to games that are developed for it.