AMD RadeonSI Gallium3D Is Now Incredibly Close To OpenGL 4.3!

[smitty3268]

i'm pretty sure it is trivial and intel have not done it because intel only needs gles for android and android has no gl4.5

The bits that are left are not trivial, per Illia who has been filling in a lot of the more trivial parts.

That streak is mostly over... I did the easy ones The only other "easy" one left is GL_OES_texture_view (and its EXT companion), but there are no dEQP tests for it. If one were to not be lazy, then one would modify the existing piglit tests to work with GL ES as well, and test the impl that way. The rest of the stuff required for AEP and GLES 3.2 is trickier - geometry/tess depend on GL_OES_shader_io_blocks, which in turn depends on making the input/output interface validation logic work for SSO programs. [Right now it just crashes on gallium since we release the IR, but even if we don't, it's till piles-o-fail.] I've been giving advanced blend some thought, but it's not trivially simple, and then there's the primitive bounding box thing which depends on tess, and cube arrays which depend on gs. And that's it. Maybe fixing GL_EXT/OES_shader_io_blocks *would* be a good newbie project, esp for someone already familiar with GL. There are dEQP tests for it, which is nice, and this is a start on the mesa bits: https://github.com/imirkin/mesa/comm...bb9b1c354690ae If you do go for it, make sure to consult with people about how to solve the issues once you identify them, since everyone will have (opposing) opinions on it. [Esp the whole reliance on the ir being around after linking -- that needs to go.]

Although i guess he said that was for GLES3.2 - not sure which bits are required for the GL4.5 extension and which ones aren't.

[castlefox]

This is great to see!

[pal666]

I'm not sure how much work is left on ES 3.1 compatibility extension for 4.5. It seems like Intel has shifted some resources away from ES support and towards Vulkan, so it may not be finished up by this summer.

i'm pretty sure it is trivial and intel have not done it because intel only needs gles for android and android has no gl4.5

[haagch]

If you're talking about the shader buffer load/store intrinsics, those just landed today:
(svn id: https://llvm.org/svn/llvm-project/llvm/[email protected]
, git: 756309c45b935a28a3bdd2ddbdebcfb27b4a1a82)

Well, the message https://lists.freedesktop.org/archiv...il/111638.html said
It depends on two patches for LLVM that have not been committed yet:
- D18340
- D18559

So, a google search:
http://reviews.llvm.org/D18340 - "This revision is now accepted and ready to land."
http://reviews.llvm.org/D18559 - "Closed by commit rL265589: AMDGPU: Add a shader calling convention (authored by nha)"

[Nille_kungen]

Congratulations AMD devs! We can clearly see here the realization of all the previous months of efforts.
And now, radeonsi is now the only driver implementation officially compatible with OpenGL 4.2!

It's nice to see all the green cells in https://mesamatrix.net

Well there are OpenGL4.2 patches for nouveau on the list for GK104 so i guess we will see 4.2 for nouveau soon.

https://lists.freedesktop.org/archives/mesa-dev/2016-April/112580.html

[smitty3268]

A separate commit yes, but why a separate set of commits?

Anyway, it's in!

Because when the original patchset was being written, it wasn't clear that it would be the final 4.2 extension to go in. It was started before the robust buffer access behaviour patches, for example.

So there wasn't really any point in modifying the already existing patchset at this point. Just push it in, and then create a new one to finish off 4.2.

[geearf]

Just good practice to keep them separate. You have many patches and commits that add all the bits required to support 4.2 - it's not all that significant that one of those patches just happens to be the last one required to meet the spec. So actually updating the docs and code to claim 4.2 compliance should always be a separate commit - applied after you've actually confirmed that you've not missed anything.

A separate commit yes, but why a separate set of commits?

Anyway, it's in!

[smitty3268]

It would be not surprising if Radeon get full GL 4.5 this summer

I'm not sure how much work is left on ES 3.1 compatibility extension for 4.5. It seems like Intel has shifted some resources away from ES support and towards Vulkan, so it may not be finished up by this summer.

The rest probably will be though.

4.3 is really the major milestone that the driver needs to be usable by modern games these days, so that will be a big deal when it finally goes in.

4.3 compute shaders (patches out - this should be committed any day now, i believe)
4.4 clear_texture (not started yet? but other drivers have it and it shouldn't be too tough i don't think)
4.4 query_buffer_object (in progress)
4.4 enhanced_layouts (patches are out - mostly reviewed but no one wants to look at the final handful)
4.5 cull_distance (patches out, needs some work)
4.5 ES3_1_compatibility (in progress)

I'm guessing 4.6 will probably get announced sometime this summer as well, so they'll still have plenty to work on with that as well as opening Vulkan and various perf optimizations.

[Veerappan]

It also needs llvm with 2 non mainline patches. Or are they mainline now? I haven't kept up.

If you're talking about the shader buffer load/store intrinsics, those just landed today:
(svn id: https://llvm.org/svn/llvm-project/llvm/[email protected]
, git: 756309c45b935a28a3bdd2ddbdebcfb27b4a1a82)

[Delgarde]

I wonder why it didn't go with this final patchset for 4.2.

Just good practice to keep them separate. You have many patches and commits that add all the bits required to support 4.2 - it's not all that significant that one of those patches just happens to be the last one required to meet the spec. So actually updating the docs and code to claim 4.2 compliance should always be a separate commit - applied after you've actually confirmed that you've not missed anything.