DSA Support on Intel HD 5500 Chips - opengl

Question

I've been hearing about DSA or Direct_State_Access extension, and I am looking to try it out, I used GLAD to load OpenGL, I first tried GL_ARB_direct_state_access extension, and called:
if(!GLAD_GL_ARB_direct_state_access) appFatal("Direct State Access Extension Unsupported.\n");
Without any problems, but I don't have access to functions like:
glProgramUniform...
For some reason, or another.... I then try GL_EXT_direct_state_access, which does give me access to those functions, but GLAD_GL_ext_direct_state_access fails, and I get an error...
On the other hand, my computer supports up to OpenGL 4.5 Core, which is odd, since DSA was core since 4.5, and therefore, there should be support
Extended renderer info (GLX_MESA_query_renderer):
Vendor: Intel Open Source Technology Center (0x8086)
Device: Mesa DRI Intel(R) HD Graphics 5500 (Broadwell GT2) (0x1616)
Version: 17.2.8
Accelerated: yes
Video memory: 3072MB
Unified memory: yes
Preferred profile: core (0x1)
Max core profile version: 4.5
Max compat profile version: 3.0
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.1
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 5500 (Broadwell GT2)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.2.8
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
What's the issue here? And how can I access those DSA functions, if I even can...

Answer 1

glProgramUniform isn't part of GL_ARB_direct_state_access but GL_ARB_separate_shader_objects. As such, you must check for GLAD_GL_ARB_separate_shader_objects (or GL 4.1) before you can use the glProgramUniform...() family of functions.
Since you seem to have generated a GL loader for 3.3 core, you must also explictely add the GL_ARB_separate_shader_objects extensions when generating your loader with GLAD.
Ttheoretically, there can be 3.x implementations supporting these extensions. But in practice, GPU vendors seldom add such new functionality to really old drivers (and 3.x only GPUs are end-of-life since several years, and only supported by "legacy" branches of the various vendor drivers.). GL_ARB_direct_state_access won't be available on MacOSX in general, and it will be lacking from most windows drivers not supporting GL 4.5 anyway. The only notable exception might be mesa itself, where many driver backends use the same base infrastructure, and where also still a lot of effort is put into supporting older GPUs.
So while it doesn't hurt to use 3.3 + some extensions which are core in 4.x, the increase (relatively to using GL 4.x directly) in the number of potential implementations which can run your code might not as big as you may hope. YMMV.