Mesa Is At Nearly 1,500 Commits This Year

[phoronix]

Phoronix: Mesa Is At Nearly 1,500 Commits This Year

With Q1'2015 quickly coming to an end, here's a look at the Mesa Git activity for the past few months...

http://www.phoronix.com/scan.php?page=news_item&px=Mesa-Q1-2015-Activity

[eydee]

So there are 683 devs, and only 2 are working on the OGL 4.0 stuff. I wonder why.

[dungeon]

So there are 683 devs, and only 2 are working on the OGL 4.0 stuff. I wonder why.

Because many of those are not active, just part of the history Some are not really full time devs, you can also send one patch and be counted as author. 683 different authors for the last 17 years, as logging goes back from year 1998.

[bridgman]

So there are 683 devs, and only 2 are working on the OGL 4.0 stuff. I wonder why.

There have been 683 devs since the Mesa git repository started ~15 years ago. I suspect the number of active devs in any quarter is much much much much much lower. There have been more than 2 working on OGL 4.x as well.

[bridgman]

The numbers for most recent quarter are probably 50-60 active devs with 4-5 of them working on GL 4.x and the rest working on bug fixes, performance or hardware enablement.

[nanonyme]

The numbers for most recent quarter are probably 50-60 active devs with 4-5 of them working on GL 4.x and the rest working on bug fixes, performance or hardware enablement.

Based on prior experiences with Mantle, would you expect Vulkan or OpenGL to require more effort in hardware enablement in the long run?

[grndzro]

Based on prior experiences with Mantle, would you expect Vulkan or OpenGL to require more effort in hardware enablement in the long run?

I would say less. There is much less bloat in Vulkan and the drivers once integrated into the command buffer should simply work as intended.

[bridgman]

I would say less. There is much less bloat in Vulkan and the drivers once integrated into the command buffer should simply work as intended.

Yeah, it depends on how high the hardware layer is in the OpenGL stack relative to Vulkan. If Vulkan ends up at approximately the same level as Gallium3D (which I think is the case) then the effort should be fairly similar, while a proprietary OpenGL driver with a higher-level HW layer would probably take more work than Vulkan.

That said, there have to be some OpenGL functions that touch hardware which are no longer required (occlusion query comes to mind, although I'm only guessing that it's no longer needed) so Vulkan should end up as lower effort.

Obviously if Gallium3D can be tweaked to cleanly support Vulkan then the answer would be "the lowest effort would be for whichever API you enable on the hardware last"

[SXX⁣]

So there are 683 devs, and only 2 are working on the OGL 4.0 stuff. I wonder why.

Because none of remaining 4.0 stuff are needed for GLES 3.1.

As @bridgman posted there is 50-60 active developers and last time I counted (here data for 2014 year) about half of them is Intel developers and they're mainly working on OpenGL ES features. E.g of course they implement extensions used for desktop GL too, but shader_subroutine and tessellation_shader isn't needed for GLES.

[imirkin]

Because none of remaining 4.0 stuff are needed for GLES 3.1.

[...]

but shader_subroutine and tessellation_shader isn't needed for GLES.

Actually that's not quite true. ChrisF got the tessellation stuff mostly into shape for core and i965. Marek and I have patches enabling tess on radeonsi and nvc0. Chris has been hitting a lot of hangs on i965, but hopefully he'll be able to get the core support out sooner so that the gallium and radeonsi/nvc0 work can land (which, btw, also still needs more work).

Also FWIW, ANDROID_extension_pack_es31a contains tess and a bunch of other desktop features (not sure if it's required by Android 5 though).