Radeon Gallium3D Tackles A Bit More, OpenGL 4.1 Patches Pending

[dungeon]

Oh no, please don't do that

I am joking there, because it is his own site i guess he can do whatever he wants or his users wants there

Maybe he can better also add kernel driver naming up there or some notice or tooltip, etc... so that user know that those differ.

[geearf]

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.

Thank you again for the detailed answer!

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.

Thank you as well!

[marek]

This should make things clearer:

[Ancurio]

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.

The part you quoted is wrong, "written against" just defines which specification this extension is a diff of. It doesn't imply any dependency.

[geearf]

And it's in:

glxinfo | grep -i opengl
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD TAHITI
OpenGL core profile version string: 4.1 (Core Profile) Mesa 10.7.0-devel (git-1b2b0e4)

[Nille_kungen]

EG/NI might catch up as only those support 4.x features in hardware, but also not all of them only high end ones support fp64.

I dunno really, who dare to include doubles in 4.0 core specs

Bobcat "Evergreen" and Piledriver (Trinity/Richland) "Northern Islands" APU are pretty common.
I don't know if the APU support fp64 but at least my laptop with Richland (A10-5750M 8650G) supports 4.2 in catalyst IIRC.
I hope EG/NI will catch up pretty soon.
I thought that maybe there are some softpipe/LLVMpipe or something that was needed for some R600 that is holding back the completion for R600, since this is not my area of expertise.

[darkbasic]

Oh no, please don't do that

Then maybe AMD developers should acknowledge amdgpu existence writing proper informations into GL3.txt

[droste]

It's using the radeonsi gallium driver. there's no seperate driver for 3D used by chips supported by the amdgpu kernel driver. So nothing to acknowledge in the 3D world.

[smitty3268]

Then maybe AMD developers should acknowledge amdgpu existence writing proper informations into GL3.txt

GL3.txt is part of mesa, and listing mesa drivers. amdgpu doesn't exist in mesa, and doesn't affect which GL extensions are present.

Please educate yourself before making stupid nonsensical claims.