Radeon Gallium3D Tackles A Bit More, OpenGL 4.1 Patches Pending

[imirkin]

At least dolphin seems to care from what I gather here:
https://dolphin-emu.org/blog/2013/09...all-fameshame/

and a faster dolphin seems like a great deal to me, but alas that's further than 4.2.. :/

Are you talking about ARB_buffer_storage? It's supported on almost all the relevant hardware already. Also note that the article in question was written during Mesa 9.x, which supported GL 3.1. Since mesa has supported GL 3.2 and various other extensions, dolphin has also made use of that functionality (like buffer storage, base vertices, geometry shaders).

Based on your reply though, is it feasible to use an extension from a higher OpenGL that the one advertised by Mesa? (because in this case the extension is already there for radeonsi).

That's right. Older GL versions would add various functionality (like GL 2.0, GL 3.0, and GL 3.2 as well as their GLSL counterparts) that was only available if you actually got that GL version. However since GL 3.2 (which added geometry shaders, and maybe some extra stuff to glsl not available via regular extensions), every new feature is actually available as an extension. So when you say "I must have GL 4.0" what you're really saying is "I must have GL 3.2 + this big list of extensions". The reality is that no one makes use of *every* piece of new GL functionality, so you could just as well have said "I need GL 3.2 + this much smaller list of extensions".

[geearf]

ooooh I see
Thank you for this explanation, it is very interesting!
Though that means no speedup with getting OpenGL 4.3 as the extension is already used :/

One more question: do some extensions depend on other extensions? or are they all independent?

[imirkin]

One more question: do some extensions depend on other extensions? or are they all independent?

Sure. For example, let's take a look at ARB_shader_texture_image_samples:

https://www.opengl.org/registry/specs/ARB/shader_texture_image_samples.txt

The spec says it depends on GL 4.3. This is another way of saying "I'm lazy and don't want to think about interactions". In reality, it just depends on ARB_shader_image_size (part of GL 4.3), which in turn depends on ARB_shader_image_load_store (part of GL 4.2).

And it *easily* could have been spec'd to require neither if they had made the imageSize() stuff dependent on the availability of ARB_shader_image_size, in which case it would have just required ARB_texture_multisample (which is where sampler2DMS came in), which became part of GL 3.2.

[przemoli]

ooooh I see
Thank you for this explanation, it is very interesting!
Though that means no speedup with getting OpenGL 4.3 as the extension is already used :/

One more question: do some extensions depend on other extensions? or are they all independent?

They do depend on something. Usually its some version of OpenGL. You can read for Yourself here:

https://www.opengl.org/registry/

ARB_buffer_storage:

 Dependencies      
This extension is written against version 4.3 of the Core Profile OpenGL    
Specification, dated August 6, 2012.      
The definition of this extension is affected by the presence of    
GL_EXT_direct_state_access.

[Tomin]

Why there is no amdgpu driver in mesamatrix?

It is. It uses radeonsi as the userspace driver.

[Creak]

Why there is no amdgpu driver in mesamatrix?

I'd like to see it too, but as long as the base file (http://cgit.freedesktop.org/mesa/mesa/tree/docs/GL3.txt) doesn't list it, I won't be able to show anything

[d2kx]

I'd like to see it too, but as long as the base file (http://cgit.freedesktop.org/mesa/mesa/tree/docs/GL3.txt) doesn't list it, I won't be able to show anything

There is no such thing as a Mesa/3D driver called AMDGPU, so I don't know what you are looking for. The AMDGPU kernel driver has nothing to do with all of this.

[bridgman]

Right. There are three stacks:

pre-GCN - radeon kernel driver, r600 mesa driver, radeon X driver (or maybe modesetting, I forget)

SI, CI - radeon kernel driver, radeonsi mesa driver, radeon X driver (ditto)

VI+ - amdgpu kernel driver, radeonsi mesa driver, amdgpu X driver

The same GL code runs over both radeon and amdgpu kernel drivers, only difference is that the bottom part of the GL driver makes slightly different calls into the kernel driver depending on which kernel driver is used.

[dungeon]

I'd like to see it too, but as long as the base file (http://cgit.freedesktop.org/mesa/mesa/tree/docs/GL3.txt) doesn't list it, I won't be able to show anything

You can copy/paste results from radeonsi and call it amdgpu

I am the one who propose to bridgman to change 'radeonsi' mesa driver name to something else, because 'amdgpu' driver users sees amdgpu driver naming everywhere, only mesa's naming differ. I guess darkbasic's confusion comes from that.

At least this is much better then 'radeon' stack, where everything had different name

[bridgman]

You can copy/paste results from radeonsi and call it amdgpu

Oh no, please don't do that