WHile I understand the move to drop Open GL support, and focus on Vulkan, I was wondering if there will be any updates to OpenGL on Windows? If not, is there a way I can assist , and help make an improved driver for OpenGL?
In what way exactly?
OpenGL 4.6 (June 2017) was essentially the "Final" Release, as Khronos Group themselves are focused entirely on Vulkan.
All it brought over 4.5 was basically some performance enhancements, bug fixes, more verbose debugging and SPIR-V support.
AMD added support in Adrenalin 18.4.1., even though most of the Point Release was focused on improving NVIDIA Support / Bugs.
Prior to that OpenGL 4.5 was released in 2014., which was the last "Major" Update in terms of Features.
The AMD OpenGL Driver is frankly as good as it's ever been and likely to get... with really no future updates.
I mean I can't think of any notable "Issues" with OpenGL that aren't simply an artefact of the GCN Architecture.
Keep in mind GCN is designed primarily for General Purpose as opposed to Fixed-Function... this means it's going to have notable performance degradation on APIs and certain Fixed-Function Tasks.
There are a lot who tend to ask "Why are GeForce GPUs typically better at Games than Radeon GPUs?" and well the simple answer is they never abandoned Fixed-Function Pipelines., where-as AMD did. Doing such comes with some trade-offs in terms of performance at certain tasks... Turning as a note also has (mostly) abandoned Fixed-Function as well., well kind-of.
It's more like they've segmented it into a Series of Cores, which means that the General Purpose is no longer being locked down by the Fixed-Function elements; that allows better General Purpose Performance … while either via Developer Support / Driver Support., they can in some cases off-load the Traditional Fixed-Function pipelines to said "New" Cores.
Arguably it's a "Best of Both" Worlds, but in practise because they are Segmented and some things do require Data Sharing (which can no longer be done outside of Instruction Cycles) well... this means there are only select cases, or when applications are specifically designed to take advantage of such where you'll actually see performance enhancement from it.
By the time most Developers begin to produce Engines to utilise such., AMD Next-Gen Radeon (GCN + VLIW/4) will have been released, meaning said Advantage that NVIDIA have in regards to this will essentially not really be capable of being showcased before there is directly competitive feature-wise hardware.
In the mean time AMD continues to improve not only the GCN Architecture for better IPC / Generation but also are becoming much more familiar with both 7nm and Chiplet Design.
Both of these are going to be extremely important over the next few years in terms of Scalability beyond the limitation of Silicon... which NVIDIA has also invested in., but down a similar path to Intel and Qualcomm. (i.e. Big Core + Multiple Little Cores all Bridged together).
I'm not sure it'll have quite the same Scalability as AMD's Chiplet approach.
In any case., you'll likely also see NVIDIA (with Turing onward) also "Abandoning" OpenGL in favour of Vulkan.
And I mean it's not surprising... this happens all the time with DirectX., as DirectX 9 / 10-11 / 12 are all very different APIs; each eventually being abandoned.
Support today isn't via Updated Drivers, but rather the Windows DirectX Emulation Layer.
Seriously, when was the last time you saw a DirectX 8.1 / 9.x / 10.x Driver Update from either AMD or NVIDIA?
What we have when they abandoned said Native Paths, essentially is what we're left with … and really there are actually A LOT of issues that stem directly from the Windows DXEL than the Native APIs.
Tomb Raider Legends is an excellent example., as it runs flawlessly on Windows XP / Vista … but has issues on Windows 7 / 8 / 10 … guess which of those are running Emulated DirectX 9 (Feature Level 9_3) as opposed to Native DirectX 9.0c; and that's just something that will occur oft with edge cases.
Would it be possible to resolve ALL of these Edge Cases? Perhaps., but it really depends on how large you want your Driver to actually be.
I'd argue that Drivers still contain the various fixes for Quake / Quake 2 / Quake 3... all because of a poor implementation, but it was the "Unreal Engine 3 / 4" of it's day; is silly... as we have what ~100-150MB of the Drivers *dedicated* to Games that basically no one plays anymore and frankly should / could instead have updated Rendering Systems (given they're open source).
Or as was another common approach, use a Wrapper., that resolved such issues; and again Modernises said Rendering Runtimes.
leyvin wrote: I mean I can't think of any notable "Issues" with OpenGL that aren't simply an artefact of the GCN Architecture.
This isn't a satisfactory answer.
If this was simply an artifact of the GCN arcitecture, why is OpenGL performance in Linux is so much better?
Why can't we have updates to the Windows OpenGL driver like they do with Linux?
There's still a few games I play regularly that use OpenGL and their performance suffers greatly. I keep hoping that perofrmance will be improved somehow but it never is - yet seemingly every week there's performance improvements for Linux.
It's extrememly frustrating.
Issues and Performance are different topics.
Issues would be if something isn't "Working As Intended", where-as Performance is the Execution Efficiency.
Why is Linux OpenGL faster than Windows OpenGL?
Well... that has more to do with how the Operating Systems themselves work rather than the implementations of OpenGL.
Like do you remember how Valve were making a 'big deal' about how their Linux (OpenGL) ports of their popular Source Engine games ran up to 20% Faster on Linux w/OpenGL Vs. Windows with DirectX 11.
Each Linux Application essentially runs as a "Self-Contained" Instance within the OS., where-as on Windows it's running as a "Shared Instance" where multiple applications are using the same Resources / Libraries / etc.
This keeps runtimes smaller... Multi-Tasking Faster... etc. but it comes at the cost of system resources that can be dedicated to said application.
It's just the nature of the OS and has very little to do with the API or Drivers themselves.
Retrieving data ...